- From: Thomas Powell <tpowell@gmail.com>
- Date: Mon, 15 Jun 2009 16:22:02 -0700
On Mon, Jun 15, 2009 at 2:14 PM, Aryeh Gregor <Simetrical+w3c at gmail.com<Simetrical%2Bw3c at gmail.com> > wrote: > On Mon, Jun 15, 2009 at 4:26 PM, Thomas Powell<tpowell at gmail.com> wrote: > > Proposing <nostyle> in the spirit of <noscript> > > > > Examples > > -------- > > 1) Head Usage > > <nostyle> > > <meta http-equiv="Refresh" content="0;url=/errors/stylerequired.html"> > > </nostyle> > > > > 2) Body Usage > > <nostyle> > > <h2>Warning: Styles required for correct rendering</h2> > > </nostyle> > > The reason that <noscript> worked is because (IIRC) it was introduced > at the same time as <script>. All browsers that supported <script> > also supported <noscript>. <nostyle> would cause all legacy user > agents to render the content even if they supported styles just fine. > Yes in the absence of our time machine it seems a bit late doesn't it. > > > And yes while that is true and for many situations will work fine, there > are > > other cases you won't and you can get a sloppy or even bad results > because > > of rendering engine paths. For example, because style is not applied > until > > later you have an issue here > > > > <h2 class="nostyle"><img src="error.gif">Warning: Styles required for > > correct rendering</h2> > > > > The network request happens regardless of situation no assuming images > on. > > That doesn't seem like a very serious issue. Just don't use images if > you care that much. A large percentage of non-CSS browsers are > probably text-based anyway. > It isn't but hints at what the motivation was from a real world request (see below) > > > For example, using the content property can be somewhat troubling if > > style is removed. For example, consider what happens if you are putting > in > > field required indicators > > input[type=text].required:before {content: " (*) "} > > This should just use HTML5's required attribute instead of a class: > > http://dev.w3.org/html5/spec/Overview.html#the-required-attribute > > Agreed that is the case, this is more documenting the usage of designers not that there isn't an HTML 5 appropriate solution. Conformant browsers should make it clear to the user that the field is > required even if styles are disabled. > yes they should. > > > or for offsite links > > a[href^="http://"]:after {content:' ( Offsite Link )';} > > This is non-essential info, and every browser I've heard of exposes it > anyway (e.g., by hovering over the link and looking in the lower > left). > > > or any other dynamic insert this way. > > Do you have any other examples where this is a significant issue? > Those two don't seem like a big deal to me, honestly, even if it were > logistically possible to get <nostyle> supported widely enough to be > useful. Those were just examples of more valid uses of content actually. Of course as I mentioned below people can abuse this property and then it does become a big deal. But dynamically having content jam in all sorts of stuff client-side seems wrong-headed so I certainly don't suggest codifying bad practices though mitigating them somehow seems appropriate. > > If CSS is necessary for a site to operate, it's probably being > misused. If an author is misusing CSS this badly, it's not clear to > me why they could be expected to reliably use <nostyle>. The contents > of <nostyle> also don't make a difference to almost anyone, so authors > who use it won't really understand the purpose it serves and it will > probably be misused more often than used. > You may be quite right. Understand my purpose of proposing this was mostly due to some contrivances to determine style and no-style support for an effort which is very contingency concerned. The solution that was adopted using scripting, server-side logging particularly triggered by image requests from background-image values or their absence, etc. can figure all cases but it was a mess and thus the "why not have a <nostyle> wouldn't life be easier" So from where you sit yes it is not that important likely, from having to wrestle with it I would have loved to have an easy solution. Anyway I will say that there is a bit of symmetry of having on/off cases for all the various client-side technologies (img, script, object, etc.), but I see that the off aspect of style could simply be thought of as the markup itself and that is certainly fine it has worked for most so far. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090615/8fba7bf3/attachment.htm>
Received on Monday, 15 June 2009 16:22:02 UTC