Re: [WSG] CAPS in stylesheets
On Mar 13, 2006, at 5:14 PM, John Wells wrote: Can we get a summary of this CAPS lesson? Are we saying that: - ONLY when serving XHTML as application/xhtml+xml, stylesheet selectors must be all lowercase. ? Some browsers are sensitive to case when XHTML is served as text/ html. iCab comes to mind. Having said that, I'm a bit confused. I wish I could remember where I read this, but I thought that *technically* (that's how I remember it being phrased) stylesheet selectors should not contain characters other than alphanumeric (and must start with a letter). Well once I read that, I moved all of my selector naming to camelCaps...so now I'm feeling squeezed. In (properly served) XHTML can I use underscores to separate my words? I strive to make my code as readable as possible (from CSS to PHP), so naming conventions are a bit of a sticking point. Why not ask the source ? http://www.w3.org/TR/CSS21/syndata.html#q6 Philippe --- Philippe Wittenbergh http://emps.l-c-n.com ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
[WSG] CAPS in stylesheets (was Re: digest for wsg@webstandardsgroup.org)
On 3/12/06, sime [EMAIL PROTECTED] wrote: I used the following as the foundation of my current approach to style sheets. http://www.w3.org/TR/REC-CSS2/sample.html However, I'm told that my code is therefore not XHTML compliant because of my use of uppercase. So who then is HTML4 relevant to? HTML 4 style CSS is relevant to HTML 4. If you are using XHTML you must write your CSS selectors in lowercase. As a habit I've never written CSS in caps, but that's just because I learned to write it in lowercase. Also please start a new thread rather than replying to the digest in the future :) -- -- Christian Montoya christianmontoya.com ... rdpdesign.com ... cssliquid.com ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
[WSG] CAPS in stylesheets (was Re: digest for wsg@webstandardsgroup.org)
Sorry about my poor subject line. Christian Montoya HTML 4 style CSS is relevant to HTML 4. If you are using XHTML you must write your CSS selectors in lowercase. So that would make HTML4 practically redundant for new web sites? To Lea de Groot: It worked in Strict which is why I've been misled for so long. Anyway, I'll fix that up and go back to being oblivious to the problems in my code. ;-) ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] CAPS in stylesheets (was Re: digest for wsg@webstandardsgroup.org)
Christian Montoya HTML 4 style CSS is relevant to HTML 4. If you are using XHTML you must write your CSS selectors in lowercase. On 3/12/06, sime [EMAIL PROTECTED] wrote: So that would make HTML4 practically redundant for new web sites? define practically redundant. I consider HTML 4.01 strict to be practically awesome for new web sites, but that's more of personal preference. -- -- Christian Montoya christianmontoya.com ... rdpdesign.com ... cssliquid.com ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] CAPS in stylesheets
sime wrote: Christian Montoya HTML 4 style CSS is relevant to HTML 4. If you are using XHTML you must write your CSS selectors in lowercase. So that would make HTML4 practically redundant for new web sites? What? I don't understand how you came to that conclusion. To Lea de Groot: It worked in Strict which is why I've been misled for so long. If you're talking about XHTML 1.0 Strict, then it will only work if you're using the wrong MIME type: text/html. Serve your page as application/xhtml+xml and I doubt it will work. -- Lachlan Hunt http://lachy.id.au/ ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] CAPS in stylesheets
No, it will not work under XHTML at all. The DOCTYPE is irrelevant, XHTML is case sensitive and uppercase element selectors will not match anything in XHTML. It will only work for text/html. I have never had a problem with the uppercase not working in strict. Maybe I'm not defining strict correctly. Here is a test page which works in FF,IE6: http://urbits.com/_/test.php ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] CAPS in stylesheets
On 3/13/06, sime [EMAIL PROTECTED] wrote: I have never had a problem with the uppercase not working in strict. Maybe I'm not defining strict correctly. Here is a test page which works in FF,IE6: http://urbits.com/_/test.php You're serving it as text/html. ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] CAPS in stylesheets
On 3/13/06, sime [EMAIL PROTECTED] wrote: Rephrased, what are the different situations in which you'd use HTML4 over XHTML1? So far I've been led to believe (outside of this list) that XHTML is a step forward. You're serving your XHTML as text/html, so it's effectively being parsed as HTML anyway. If you were using XHTML served as application/xhtml+xml (is that right? can't recall the exact string right now...), which is as it should be if you actually have a reason for using XHTML aside from it's like HTML, only... extensible! (without knowing what extensible entails) then every time you had a trivial markup error browsers would give a nice big parser error page (with the exception of our esteemed friend Internet Explorer, which doesn't even attempt to render pages served as anything other than text/html). XHTML *could* be a step forward if you desparately need to be able to parse your pages and use XSLT or something, but barring that there's absolutely nothing wrong with HTML 4. Even with XML, it's only sensible to use a schema with widely recognised semantics -- so, whilst you can theoretically add your own elements, etc., to an XML document, there's no point if these elements exist outside the vocabulary of any parsers (I'm thinking specifically of search engines, but there are others for which this matters). With XHTML for today's web, you can only really consider using it as HTML anyway (unless you have a highly controlled intranet environment, but that's internal) in terms of how it's served, and the scope of the schema: and this latter point is unlikely to vary much even in the future, one would hope, for the sake of backwards-compatability. Josh ~ who hasn't ranted about XHTML vs HTML before at any great length and may be slightly off on the specifics of certain points ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] CAPS in stylesheets
sime wrote: No, it will not work under XHTML at all. The DOCTYPE is irrelevant, XHTML is case sensitive and uppercase element selectors will not match anything in XHTML. It will only work for text/html. I have never had a problem with the uppercase not working in strict. Maybe I'm not defining strict correctly. Here is a test page which works in FF,IE6: http://urbits.com/_/test.php Add this function call to the top of your PHP file: ?php header(Content-Type: application/xhtml+xml); ? -- Lachlan Hunt http://lachy.id.au/ ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] CAPS in stylesheets
Christian said: I think you might be alluding to using XHTML 1 served as text/html. It's just as harmful as helpful, IMO, to the future of XML on the web. People see XHTML pages served as text/html with errors and otherwise non-xhtml behavior and think that XHTML is just another tag-soup language that can be abused like HTML is. [1] I'm not going to go any further into that territory as there's a lot of past discussions on this list covering the same topic. The point is that any XHTML 1 doctype served as text/html could just be changed to an HTML 4 strict doctype and the display will not change at all. Thankyou Christion - that explanation helped me immensely. I wish I'd read that when I was first researching this aspect of web design. ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] CAPS in stylesheets
Joshua Street wrote: (with the exception of our esteemed friend Internet Explorer, which doesn't even attempt to render pages served as anything other than text/html). ...or text/plain. But that's another can of worms :-) -- Lachlan Hunt http://lachy.id.au/ ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] CAPS in stylesheets
sime wrote: define practically redundant. I consider HTML 4.01 strict to be practically awesome for new web sites, but that's more of personal preference. Which brings me back to my original question question. Rephrased, what are the different situations in which you'd use HTML4 over XHTML1? So far I've been led to believe (outside of this list) that XHTML is a step forward. Many people, especially editor developers, have been implementing default DOCTYPES as either XHTML transitional and XHTML strict and many authors of great books have done the same but from what I understand is that many of these people have adopted XHTML incorrectly simply because it is newer. Unfortunately, is is not made clear by the W3C -- in plain English and succinctly that it (XHTML) is not a replacement or update for HTML but a different spec altogether. There are uses for XHTML, but for most computer based web browsers there is no real advantage to XHTML as they just treat it as HTML anyway. I have also read (no personal first hand knowledge) that there can be issues between using DOM/DHTML scripts and XHTML. I don't know what these issues are but why invite trouble. I think many standards oriented people have moved or stayed with HTML 4.0X and those who are using XHTML are either using it incorrectly and unknowing of its proper application or the minute few who are actually serving it as application/xhtml+xml. Jay -- Jay Gilmore Developer / Consultant SmashingRed Web Marketing P] 902.529.0651 E] [EMAIL PROTECTED] U] http://www.smashingred.com B] http://www.smashingred.com/blog ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] CAPS in stylesheets
sime wrote: Which brings me back to my original question question. Rephrased, what are the different situations in which you'd use HTML4 over XHTML1? So far I've been led to believe (outside of this list) that XHTML is a step forward. Ah, but, grasshopper, to step backward from the precipice may be a sign of wisdom ;-) It's really a case of you say tomahto, I say tomayto Some will tell you that there is no real need for XHTML, that it confers no special capability that websites require now and for the foreseeable future. Others will tell you it's the greatest thing since sliced bread, and will in fact slice your bread for you (as long as your breadbox is defined in XML). My advice would be for you to analyse your project, analyse the options and determine which meets your needs best. If there are tags in XHTML that you can't live without, your choice is made. If you find you don't absolutely need it, then the choice is yours to make. Be aware that XHTML is less forgiving than HTML (even strict) and that most browsers currently won't care what you use, although even IE may barf on badly formed and served XHTML (or you might get lucky) cheers mark ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] CAPS in stylesheets
On 3/13/06, Jay Gilmore [EMAIL PROTECTED] wrote: I have also read (no personal first hand knowledge) that there can be issues between using DOM/DHTML scripts and XHTML. I don't know what these issues are but why invite trouble. This arises from non-DOM methods, which are often much simpler to implement (and faster in terms of performance), such as innerHTML [1] (and document.write, but we won't go there). I *think* this is because innerHTML/outerHTML/document.write and their kin leave the XML tree alone -- any elements in the inserted content _aren't_ created as elements, and hence cannot be manipulated at all. (That aside, I don't really see anything wrong with this [innerHTML] -- we must remember that XMLHttpRequest object is also proprietary!) Obviously if you do this with an XML document then you wind up with un-parsed structure (it renders, but it's not part of the tree), which can mean problems. Apparently Firefox 1.5 copes okay with this, somehow. Josh 1.http://www.quirksmode.org/dom/innerhtml.html ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: [WSG] CAPS in stylesheets
Jay Gilmore wrote: I think many standards oriented people have moved or stayed with HTML 4.0X and those who are using XHTML are either using it incorrectly and unknowing of its proper application or the minute few who are actually serving it as application/xhtml+xml. Don't forget those of us who actually serve our XHTML as 'text/html' for now - *after* having made sure it works when served as 'application/xhtml+xml'. We're just waiting for the day we can safely change MIME-type again. Lachlan Hunt wrote: Joshua Street wrote: (with the exception of our esteemed friend Internet Explorer, which doesn't even attempt to render pages served as anything other than text/html). ...or text/plain. But that's another can of worms :-) We can go fishing... ;-) regards Georg -- http://www.gunlaug.no ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
Re: innerHTML (was: Re: [WSG] CAPS in stylesheets)
Joshua Street wrote: On 3/13/06, Jay Gilmore [EMAIL PROTECTED] wrote: I have also read (no personal first hand knowledge) that there can be issues between using DOM/DHTML scripts and XHTML. I don't know what these issues are but why invite trouble. This arises from non-DOM methods, which are often much simpler to implement (and faster in terms of performance), such as innerHTML [1] (and document.write, but we won't go there). I *think* this is because innerHTML/outerHTML/document.write and their kin leave the XML tree alone -- any elements in the inserted content _aren't_ created as elements, and hence cannot be manipulated at all. Um... What the? Of course they are created as elements, or at least they should be, unless you're talking about some strange IE bug I'm not aware of. (I never use innerHTML so I'm not aware of all of its quirks.) AIUI, the way innerHTML is supposed to work is that the value is parsed as HTML or XML (depending on whether the document is HTML or XHTML; which is determined by the MIME type, not the DOCTYPE) and a DOM DocumentFragment is created. If it's XHTML, it should result in an error when the value is not well formed. Mozilla does this, but Opera doesn't because it always parses it as HTML. I'm not sure about other browsers. All children of the element are then removed from the tree and the new DocumentFragment is appended. I believe Mozilla internally uses its proprietary range.createContextualFrament() function to do this. (That aside, I don't really see anything wrong with this [innerHTML] -- we must remember that XMLHttpRequest object is also proprietary!) The problem is not that it's proprietary, there is actually work to get it standardised as part of the WHATWG's Web Apps proposal. The problem I have with it is that it's working with strings to manipulate the DOM, and those strings need to have escaped characters which get's quite messy, much like document.write(), but not quite as bad [1]. For instance, just to write one simple element with an attribute, it needs to be like this: script ... foo.innerHTML = p class=\bar\text\/p ... /script My other problem with it is that it's specific to (X)HTML, not any generic XML like the rest of the DOM API is (except for, of course, DOM 2 HTML). IMHO, Mozilla's createContextualFragment() is much more useful for any DOM and I would like it to be standardised, but I don't see that happening any time soon. A much better alternative is to use E4X which is specially designed to make working with XML very easy, as XML is a native data structure, but support is currently too limited for real world usage. [1] document.write() is bad because of the way it throws more markup back to the parser during parsing which means instead of having a nice flow like this: input -- parser -- tree constructor -- output (DOM) document.write() makes it more like this: input -- parser -- tree constructor -- output (DOM) ^| |___doc.write()__| -- Lachlan Hunt http://lachy.id.au/ ** The discussion list for http://webstandardsgroup.org/ See http://webstandardsgroup.org/mail/guidelines.cfm for some hints on posting to the list getting help **
