boen_robot
-
Posts
8,493 -
Joined
-
Last visited
-
Days Won
1
Content Type
Profiles
Forums
Events
Everything posted by boen_robot
-
I just had a flash of a h#ll of a stupid idea!@aspnetguy or anyone else on that manner. Do you have enough skills with C++ or something to enable some support for such fen extensions of ours? Or is it just too much to ask? I mean FF is Open Source, but I for one don't have the skills to manipulate it's code. And even if I did, I can't say if it's worth it.
-
No, the XML prolog is not necessary. At least not when you serve the page as text/html, where the XML prolog has no meaning whatsoever. And thank W3C for that too. IE6 has a bug which sets it back to quirksmode if you use the XML prolog.
-
Well, you can have MathML in an XHTML 1.1 page, but it has to be served with it's correct MIME type of application/xhtml+xml, making it useless for IE.But yes, you can have XML with XSLT that would transform the XML into a fancy XHTML. Browsers with MathML support should show the MathML code, and ones without MathML support but with XSLT one will show the XHTML.
-
Well, perhaps it really doesn't support them. There has to be some difference if those types of connections are on different ports after all .Why is port 21 closed anyway? Can't you open it?
-
There has to be a way. It's just missing in the tutorial (and I don't know it either). XML Schema is a very powerful language. It's just that the tutorials don't cover all of it.
-
Like kvnmck18, I can't get your point either. XSLT is exactly the language to convert one XML into another XML based language. On W3Schools you can see XML-to-XHTML examples, but if you just rename <html> to (for example) <mytag>, <table> to <anothertag> and so on, you'll get an XML-to-XML transformation. Everything in XSLT which doesn't use the XSLT namespace (<xsl:*>) is part of the output, and what's the output depends totally on you.
-
...and to be more precise, use a predicate. Something like this: <xsl:for-each select="rss/channel/item[position() <= 5">
-
I've never heared about anything else other then XML Schema and DTD. Those are THE best methods. They are both W3C reccomendations too. XML Schema has more advantages, so it's better. The only "weakness" which is also it's strongest point is that it's based on XML. That's where DTD comes in. It's based on text, thus leaving the XML advantages away.
-
I think I've got a solution. Instead of applying filter to different modules, apply gradient instead, like this:gradient: value;background-gradient: value;border-gradient: value;etc.Where as you can guess, gradient only is a shorthand property for defining a gradient for everything in an element.Adding Opacity as a submodule to every existing module could also be a good idea. As far as I'm aware, currently the Opacity property sets opacity to everything, right? If not, it should.Now the syntax of gradient.... hmm... it could be something like this: background-gradient: FirstColor OffsetX OffsetY, SecondColor OffsetX OffsetY; Example: background-gradient: #000000 0 0, #FFFFFF 0 100%; And a simmilar thing for opacity, with the difference that it would use a value from 0 to 1 as it's first argument, as the Opacity property does, for example: border-opacity: 1 0 0, 0 0 100%; As you can realize, this makes the things a bit complicated. Well, at least this model could allow the addition of other submodels as well. For example: background-gradient-color: #000000 #FFFFFF;background-gradient-offsetx: 0 0;background-gradient-offsety: 0 100%; And before you ask- NO. Separating the different stop's properties is a bad idea. It would make the module definition much too complicated. Imagine adding "-[number]" to every submodule currently defined. Bad, bad, bad.I think this solution also calls for it's own issues, such as inheritance, but I'll try to explain myself a bit later, cause thinking up this wasn't as easy as it may seem (phew... Now I truly understand why CSS was developed in such a long time).[edit] OK. I think my mind is just a bit fresher now. So as I was saying, because we define a new property, there comes the relation with existing ones. We already saw how the opacity submodules rely with the Opacity itself, so that won't be much of a problem, or at least I don't think it should be. However, gradient defines colors and colors are avaiable without gradients too, so...What should happen if any of the colors is set to "inherit"? I think that the color of the element should be taken. If there's no specified color on the element, then the value of the one above it should be used and so on. And if any of the color values is set to none... well I've got some problems figuring this out. I mean we've got opacity for transparency and above, I even added the feature of gradient transparency. We can't just ignore "none" either. It's part of the color module we take use of.[/edit][edit] Oh no. I just realize the worst issue my model has. It can't apply to the shorthand property background and because of that, it doesn't have any chances. The Solution must be applicable with existing properties of the module if it's going to be a submodule. Perhaps if linear() is added? Something like background: url('image.jpg') #000000 linear(#000000 0 0, #FFFFFF 0 100%); Should be the equivalent to background-image: url('image.jpg');background-color: #000000;background-gradient: linear(#000000 0 0, #FFFFFF 0 100%); but then again, this means the submodules of gradient are out. Oh well, if it's going to keep the gradient, that's a good enough sacrifice.[/edit]
-
Yup. That's definetly a lot of power, most of which is absent in the gradient() model. Oh well, let's look for an alternative shall we? Apparently, gradient's place isn't as a property's value. It's much too complicated. Perhaps if each module adds a -filter to it with those properties. For example: border-filter: Alpha(Opacity=20, FinishOpacity=100, Style=1,, StartX=0, StartY=0, FinishX=0, FinishY=50); Would apply only to border and background-filter:Alpha(Opacity=20, FinishOpacity=100, Style=1,, StartX=0, StartY=0, FinishX=0, FinishY=50); Would apply only to the backgorund.Other issues arise then though. The Opacy property is already a standart, and using only filter allows for opacity changes, making the Opacity useless. Having a gradient transparency is a good feature though, so getting rid of it without an alternative isn't so appealing. There are also other syntax problems that arise, but they are so complicated, that I don't feel in a mood to describe them right now. The only thing I can point our right now is what is the style=1 for anyway? And those two commas after it...
-
I can already tell you why filter isn't a reccomendation. It only defines the style for the inside of an element. You can use it to create a gradient for the main part of an element (the same as to using background-color: gradient(something); ), but you can't use it on other things such as borders (Equivalent of border-color: gradient(something); ) so our model is infact better then filter's, despite the fact that no one is using it.That also explains why SVG requres a whole new element in the file just to define the gradients. There are so many things in one gradient to describe, yet they must be applicable on more then the inner of an element.By the way, I must say that I have actually seen this gradient() model considered in CSS's mailing lists, but issues such as the ones I pointed already and other ones I can't remember right now were pointed out, which is the reason this wan't brought to a Working Draft state.@aspnetguy actually, how do you define gradients in the filter property? The issues I pointed out were about filter being another property, but it's syntax may be of help.
-
Currently no, but who knows. If we come up with a brilliant idea and someone posts it on his/her site, then throw in the spark at some browser vendors, we might get lucky some day. Sure, we will never be credited, but do you care? I don't.Besides, isn't it fun pretending to be a creator of specifications ?
-
Well then, perhaps there should be horizontal-gradient(#FirstColor,#SecondColor) and vertical-gradient(#FirstColor,#SecondColor) but there arises the issue to what should happen if horizontal or vertical is ommited. Both horizontal and vertical? or perhaps a radial gradient?There's also one more thing. SVG defines a way to use stops as to point where the different absolute points of each color should be. The way you currently define it, stops are at the two ends of the element, right? But what if I wanted to have a gradient from black to white only on 50% of the page, and keep the rest as the second color (in this case, black)? Hmmm.... perhaps hardcoding the middle as a third color would be best. Something like: horizontal-gradient(#FFFFFF,#000000,#000000) Which should perform well in this manner. But then again, a stop might be requred at a more non-centrical place, such as having only a 3% gradient and keep the rest a solid color. Hardcoding the gradient in the current manner would make this small thing take a lot of text.P.S. I know I'm being an a$$ as to pointing issues with your ideas, but hey, CSS wasn't created in one day.
-
Here is something to think about... gradients in CSS. How do you think they could be made? As far as I'm aware, CSS3 doesn't currently define a way to create gradients and in SVG there is a need for a <gradient> element inside <defs> in order to create a gradient, then use the CSS property with a url(#gradientName) to which that gradient should be applyed. How do you think such think could be achieved with XHMTL and CSS without requring an additional element in the XHTML the way SVG does? Remember that your solution should be compatible with current versions of CSS and still keep it as simple as possible, yet giving as most possibilities as the SVG solution.
-
You might want to read the CSS3 line module before you go any further in explaining your ideas. I mean, there must be a better way without losing CSS's flexibility. If not anything else, a new property maybe.I only hope I'm not discouraging you by saying this though, so please, keep 'em coming. I would just remind you we're talking about specifications, not browser support. If a feature you requre is present in CSS3's specification, but it's not supported, that's not our problem here.
-
I was recently thinking (while I was in aspnetguy's forum)... what would you change in a certain technology you know? What if you were part of W3C? What would you suggest to them? Explain your thoughts too.For example, what feature would you add in CSS that hasn't already got an alternative? What would you deprecate and what do you propose for a replacement? Note that we're not talking about browser support, but for specifications.Should I give you a start? OK. In SVG, I think presentational attributes that have CSS alternatives should be deprecated. The reason is simple: they are already in CSS. Scince the style attribute is avaiable in SVG for performance reasons, the presentational attributes themselves don't hold anything unique. Examples of such attributes are width, height, fill, stroke, etc.P.S. Imagine some person that is part of a W3C member organization is going to see this and make a note. Wouldn't it be cool
-
Strange. Such error shouldn't appear with HTML files. It should however occur if your file is served with the MIME type text/xml or application/xml. Or simply if it's extension is *.xml rather then *.html. Can you give a link to both the working file and the non-working one?
-
Is this even displaying anywhere? Try to move the <html> element right after the <xsl:template match="/"> tag. Currently, your XSLT itself is invalid.
-
What are you talking about? It works in FF and Opera 9 too. Perhaps your XHTML output wasn't actually valid, so that's why you got some inconsistences. Show me the code you've tested.
-
There's the XSLT tutorial, but you're probably refering as to how to create attribute in the output.
-
Honestly spaking, I'm up for justsomeguy's first idea, but maybe that's just the teenager in me speaking .
-
What do you mean you store pictures in XML? References to puctures, simmilarly in XHTML's <img> element? If so, then simply learn (and use) XSLT for this (and any other type of XML-to-otherXMLbased transformations).
-
Yes. Absolutely correct. It's not a standard and therefore it's not supported yet. If you're going to be using ASP to parse XSLTs, you could look for another XSLT 2.0 aware processor. The most famous I know of is Saxon. I don't know the installation drill though. You're on your own there .
-
Can't you just use the include element or you have something non-schema thing to include?
-
Correct, I mean no one is forcing you to make websites. If you don't have anything interesting to publish and/or maintain, why were you into this on the first place ?Hmm... I see the point. Oh well, you were already given the best possible options. What better thing to use a domain matching your nickname then a personal site .