Re: [whatwg] WA1: rev attribute
On Mon, 18 Jul 2005, fantasai wrote: > > The 'rev' attribute from prior versions of HTML is missing in WA1, and I > think it deserves not to be left out. Most common link types out there > are used with 'rel', but some 'rev' values can also be useful. Actually, research suggests that rev= is basically only used when authors make mistakes. The most common rev="" value is "made" (11 million pages out of a billion pages), which is redundant with rel=author, and the second most common one is "stylesheet" (2 million out of a billion pages), which is a mistake. The next most common value is "owns" (110 thousand pages out of a billion), which I don't understand, and the fourth most common value is "author" (50 thousand out of a billion), which seems to be a mistake as well. This is a very poor track record for a feature. > Here are some use cases: > - rev="footnote" for a link back from the footnote or endnote to > the source anchor in the main text This could be handled by a rel value, e.g. rel=source. > - rev="help" for a link to the part of the site that the help > text is about ...as could this. > - rev="author" on a personal site or resume for links to documents > s/he has written Why need a rel type at all for this? > See also http://www.eastgate.com/HypertextNow/archives/Trigg.html > for a direction link types could go in which 'rev' would be useful. > Many of the link types suggested there would be easier to use with > rev for the reverse link than with a separate keyword that means > the inverse relationship. > Example: > rev="refutation" to link to the article one is refuting I think we should work the other way around. We should start with a problem, and work out the solution, not the other way around. On Mon, 18 Jul 2005, Matthew Raymond wrote: > > > >- rev="footnote" for a link back from the footnote or endnote to > > the source anchor in the main text > >- rev="help" for a link to the part of the site that the help > > text is about > > This is largely useless, as you are unlikely to start at a help/footnote > document and go to the document for which the help document was written. > The most common situation is that you clicked the help/footnote like > from the parent document, and therefore the relationship is already > established from the parent document. I agree. > >- rev="author" on a personal site or resume for links to documents > > s/he has written > > Here, you're using |rev| to replace missing metadata in the target > document. What happens when is defined in the > target documents? Does |rev| override? What would a UA do with the > information anyway? If there's a link, wouldn't there be text stating > that the creator of the personal site created the document the link is > to? Indeed. > > See also http://www.eastgate.com/HypertextNow/archives/Trigg.html > > for a direction link types could go in which 'rev' would be useful. > > Well, I scanned over it, and I noticed one good point. People often > don't bother putting in relationship types for links. Therefore, |rev| > could establish what the relationship is when you reach the target > document. The problem is that the argument is mostly self-defeating. If > people fail to use |rel|, how is a reverse version of that same > attribute going to be used with any frequency. Evidence suggests it is not. > At least with |rel|, you could harvest hyperlinks and put them into a > link toolbar. With |rev|, you're describing the relationship type of the > current document. Therefore, I really don't see what user agents are > supposed to do with |rev| and how they can create a useful interface > that can exploit this attribute. Indeed. On Mon, 18 Jul 2005 [EMAIL PROTECTED] wrote: > > The user interface of rel and rev can be exactly the same, only rev > under the heading of "reverse". In practice, it seems authors and users alike don't really care for this. > AFAIK there is no difference between > > > > and > > Indeed. So why have rev=next? On Mon, 18 Jul 2005, Matthew Raymond wrote: > > So, functionally, you're just breaking a link toolbar into two > categories: "forward" and "reverse". What's the use case for this? > Surely a "Previous" button in your links toolbar is better than > "Reverse->Next" from a UI perspective. Or are you suggesting that the UA > should determine the reverse of the relationship and present a button > for it? That's really bad for things that don't necessarily have > inverses: > > |rev="top"| -> "bottom"? > |rev="first"| -> "last"? > |rev="top"| -> "bottom"? > |rev="ToC"| -> ?? Indeed. > Also note that "refutation" is a bad example, as it would only ever be > used in |rev|. Does anyone ever link to a refutation of their article > from the article itself??? Good point! > So what we're seeing is that |rev| encourages us to define relationship > types specifically for |rev
Re: [whatwg] typing links
On Tue, 30 Oct 2007, Ben Adida wrote: > On 30 Oct 2007, Ian Hickson wrote: > > On Tue, 16 Nov 2004, Ben Adida wrote: > > Wow, that was a while ago :) Hey, I said I'd reply to all feedback. I just didn't say when! :-) > > Actually URLs are already allowed in HTML5 -- anything that doesn't > > contain spaces can be used. > > Given the progress we've made since Nov 2004, my interest at this point > goes beyond @rel: I'd like to see a way to make RDFa work in > HTML5/XHTML5. Where would be a good place to start? As with any new feature, the best place to start is to work out what the underlying problem is (for authors or users). For example, with , the problem was that there was no progress bar control, and that authors were therefore faking progress bar controls with s and s, which was making the user experience inconsistent with the native UI, as well as making it hard for non-visual users to determine what was going on. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Context help in Web Forms
On Sun, 12 Jun 2005, Derek Featherstone wrote: > >> > >> Anyway, having the ability to add a help link in the body, with > >> particular context-sensitivity (as discussed for including a link > >> with rel="help" in a form control label) is probably sufficient. I'll > >> take that discussion back to W3C's Protocols and Formats group (the > >> part of WAI that deals with review of specifications to ensure they > >> enable accessibility) and see what they think... > > > > Great! Thanks. I think your idea of making rel="help" be relative to > > the nearest parent is a good one. We could also say it is > > relative to the nearest parent , , , , > > , or other such grouping element. I'll look at this in more > > detail when defining the rel="" values. The spec makes it relative to the parent of the element. > I've actually been thinking about that for a while - rather than leaving > it to a "guess" why not bind it specifically with something like an > about attribute that identifies the specific element/node it references? > > rel="help" about="#phone-number" > > That would allow for much more flexibility and robustness wouldn't it? On Mon, 13 Jun 2005, Matthew Thomas wrote: > > Or perhaps , to be consistent with > the for= attribute in . This is a possibility, but is it really needed? In general it seems we'd want to encourage authors to put the links near the text and controls to which it applies. > Many applications provide inline help which is not a label, and the same > attributes would be appropriate here: for="phone-number">The full number, including country code. > Example: +61 3 1234 5678 How would UAs use this? > The cite= attribute was also mentioned in this thread as one that is > practically useless because there is no good way of presenting it. > (Sometimes authors use JavaScript to pull it out of a and > present it as a link underneath. But that still has accessibility > problems, because it doesn't work without JavaScript, and the resulting > link text is either a raw URL or the same text for every quote. These > problems make the technique even more unworkable for .) As a result, > authors usually use an link to the resource they're quoting (look at > most self-hosted Weblogs for examples), and there ends up being no > machine-readable connection between the link and the quote. This could > similarly be achieved in the element with a for= attribute giving > the ID of the or element. Interesting idea. > The majority of authors still wouldn't use these attributes, because it > would give them no presentational benefit. But at least authors would be > slightly more likely to use them than to use attributes that they have > to re-present using extra elements or JavaScript. We should probably aim higher than that though... -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Web Apps 1.0: On-line help
On Tue, 10 May 2005, Lachlan Hunt wrote: > Jim Ley wrote: > > adding in a link rel of help would seem a pretty low rent thing to > > define, > > There's already a "help" relationship defined in HTML 4 [1], it doesn't > need to be added. Perhaps it's semantics could be refined and maybe > give some examples of use and describe some possible implementation > methods. Indeed, it is now defined in HTML5 too. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] A thought:
On Fri, 6 May 2005, Ian Bicking wrote: > > I was just thinking about the recent problems introduced by the Google > Web Accelerator following links that have side effects (the typical href="form?delete=10">[delete this] stuff). One of the issues is > that doing the Right Thing means creating a form, and that effects the > UI, and of course the nesting form issue and all that. The Web Forms > spec deals with this some, with the action attribute for submit buttons > and some other details. > > A related extension might be a method attribute to anchor tags. One > might expect [delete this] to > do a post request to "form" with a request body of "delete=10". Or it > could do a post with an empty request body, but unfortunately a large > number of web frameworks ignore URL variables in post requests. An interesting idea. > The benefit is that this would be easy to apply to current applications, > would generally be backward compatible with all user agents (as long as > the server respected GET responses), and can be implemented in > Javascript fairly easy. And for many applications this is purely a > template change, not requiring any server code changes. The Google Web > Accelerator will still be broken (the method attribute wouldn't > magically appear on all the many applications out there), but at least > conscientious web developers would have a fairly simple option to do the > right thing. > > Anyway, just an idea that occurred to me; I tried searching the archives > a bit and didn't notice anything on the topic. My feeling now isn't really different from my feeling when you originally posted this: On Fri, 6 May 2005, Ian Bicking wrote: > > > > This has been brought up several times, although I don't remember the > > past reasonings for it not being added to the spec. > > > > The main problem I have with it is that it feels wrong. (Yup, I'm > > giving really good arguments today!) The element is supposed to be > > a hyperlink -- but if you say it can be a form submission, that breaks > > that model. Fundamentally, I feel users should be able to always treat > > hyperlinks as safe-to-click -- they are links. > > > > So I would say that any time an author needs something to have UI that > > is a submission, it should be clearly submission UI. And that would be > > a or , not an hyperlink. > > > > In short, I would say that delete is > > fundamentally wrong. > > I'd basically agree. Which perhaps makes the argument stronger -- I > agree, and yet when I'm actually writing an application I frequently do > this anyway ;) This is such a common practice, and at least > method="post" offers a path to get people to move in the right > direction. Some of the motivations for using anchors is removed by Web > Forms, but not entirely. Given that you can now easily make a submit button without a form, it would be interesting to see if this reduces the demand for this: > It's not 100% clear to me how you'd do the equivalent with . I > guess this is what I'd come up with... > > > ... > delete this Actually it's simpler. You can just do: delete this No need for a form. > And that's not too bad. If you really didn't want it to look like a > button, you could go out of your way to use CSS to do that. If the UA > allowed it (if the UA actually allowed that). But one major reasons for > buttons not being used (besides currently requiring Javascript) is that > they don't look very nice in long lists, so control over appearance is > important. But using anchors for actions is so engrained in web > developers that it might not be enough of a carrot. It's hard to know... testing it (by having browsers support the above and then seeing if authors adapt over the following years) would be a good test, I think. > > But having said that, a lot of people have asked for this kind of > > thing. Should we give up on our ideals in this particular case and > > just say that the "method" attribute can change the from being a > > simple hyperlink to being part of a submission UI? > > I must admit I don't know what you mean by "submission UI". If you > mean, act like a submit button for the containing form, then no, people > use anchors specifically to avoid that. Or do you mean something else? I mean, act like a link but do a button's work. On Sat, 7 May 2005, Daniel O'Connor wrote: > > Is this perhaps a problem that is solved with rel="nofollow"? > > I can see where it would be beneficial to have a profile of link > relationship types to denote functional links. > > ie > > to say "this is a link which is used for editing and administration, > don't follow it". > > That neatly describes the link functionality in a set of known terms, > and avoid a lot of the mess with prefetching... Ironically, nofollow doesn't really mean that it shouldn't be followed, just that the linking site doesn't endorse it (e.g. because the link was added by
Re: [whatwg] Fwd: idea for new tag: breadcrums (fwd)
On Mon, 6 Dec 2004, George Lund wrote: > Ian Hickson <[EMAIL PROTECTED]> writes: > > > > Someone sent me a mail suggesting: > > > > | > > | Main >> Products >> Dishwashers > > | > > > > I think a better way of doing this would be: > > > > > > > > Main > > > Products > > > Dishwashers > > > Second hand > > > > > > > > ...where we define rel="up" to mean "go up one level" (as now) and add the > > semantic that if the keyword is repeated, then it means up that many > > levels. I've noted this as something the spec will have to talk about. I've now added this to the spec. Let me know if you see any problems with it. > URLs already have these semantics built-in. means > something special to web browsers without having to invent a new way of > doing that. What would these keywords do extra that can't already be > done if authors organise their URL-spaces sensibly? Well, some people can't organise their URL-spaces sensibly. Also, the URL space can only represent one hierarchy. > The idea of a element would be very useful (like giving > speaking browsers the chance to skip their contents, for example). We now have . > But I don't see why that mark-up should be added, as what we have > there isn't a normal paragraph in most human languages. It's more like > some kind of specially-ordered list, if anything. Yes, would also work here. On Mon, 6 Dec 2004, Olav Junker Kj�r wrote: > > By sensible URL-spaces, I assume you mean using slashes in URLs to > indicate the hierarachy? This is not really practical since it won't > work with many CMS'es, and it prevent you from moving rearranging the > hierarchy since this will break links. URL's should be allowed to be > opaque. Indeed. On Tue, 7 Dec 2004, George Lund wrote: > > Well, HTTP has well-defined ways of indicating that a resource has > moved. HTML shouldn't be trying to take over from these established (and > well-designed) divisions of labour within the system. > > What's proposed is a system where people (or processes) are forced to > edit the _contents_ of an object just because it has moved, whereas > conceptually moving something around in a hierarchy doesn't necessarily > require any modification of the object's contents at all. I think I'd > be correct to point out that such a situation wouldn't be very > 'RESTful'. Sure. But sometimes a resource is in two (or more) hierarchies at once, and then you can't use the URL space anymore. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] typing links
On Tue, 16 Nov 2004, Ben Adida wrote: > > The REL attribute has been proposed as a means to extract *simple* > meaning from the HTML. For example: > > > By viewing this web site, you are agreeing to its href="terms-of-use.html">terms of use. > > > UAs could theoretically implement special UI for some of these typed > links, though certainly it wouldn't be required. Most importantly, an > automated crawler could glean structured properties from these typed > links in HTML. > > And, of course, in order to handle the scoping problem of these names, > one should allow fully qualified names in the REL. What scoping problem? > Thus, the HTML above could make use of well-defined properties like > those of Dublin Core, and look like this: > > > By viewing this web site, you are agreeing to its rel="http://http://purl.org/dc/elements/1.1/rights"; > href="terms-of-use.html">terms of use. > > > The only thing that's necessary to enable this right now is to allow the > REL attribute to be a fully qualified URL. HTML 5 need do nothing more, > and no requirements need to be made of the UAs. It's an easy way to add > structure to HTML documents without having to define all the possible > structural terms. Actually URLs are already allowed in HTML5 -- anything that doesn't contain spaces can be used. http://www.whatwg.org/specs/web-apps/current-work/#rel Cheers, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Full screen for the element
On Oct 30, 2007 9:20 PM, Dave Singer <[EMAIL PROTECTED]> wrote: > I think if you can collect keystrokes then phishing is also on the cards, > alas. > FWIW, Flash and Silverlight try to address this by leaving full-screen mode when keys are pressed. Rob -- "Two men owed money to a certain moneylender. One owed him five hundred denarii, and the other fifty. Neither of them had the money to pay him back, so he canceled the debts of both. Now which of them will love him more?" Simon replied, "I suppose the one who had the bigger debt canceled." "You have judged correctly," Jesus said. [Luke 7:41-43]
Re: [whatwg] additional empty elements
On Tue, 1 May 2007, Brenton Strine wrote:
>
> Say, for example, you have a website which has sections of content that
> are indented variously. It would be easy to accomplish the different
> styles using classes:
>
> This text isn't indented at all!
> This text is indented a little.
> Lots of indentation.
> No indentation here!
In general you should try to avoid using markup like this, which is tied
to the presentation, and instead use markup that describes the meaning of
the document, and have stylesheets keyed to that.
> However, if I then wanted to add additional special styling to the first
> and third div, (e.g.. a border and background color) it is less
> graceful. I could add style attributes, but that would be wasteful if I
> want to do this on a large scale. Multiple classes would be confusing.
I don't see why multiple classes would be confusing.
> A nice solution would be the addition of a few div tags. (e.g. ,
> , and .) Then you could do something like this:
>
>
> div1 {text-indent:0px;}
> div2 {text-indent:10px;}
> div3 {text-indent:20px;}
>
>
> Then:
>
> This text isn't indented at all!
> This text is indented a little.
> Lots of indentation.
> No indentation here!
>
> This is much more human-readable, and the addition of additional styles
> is now elegant and easy with the use of classes.
>
> This text isn't indented at all!
> This text is indented a little.
> Lots of indentation.
> No indentation here!
I'm not sure I agree that this is more elegant.
> I also think that it would simply be easier to write code if there were
> a few extra non-semantic empty tags. HTML5 needs improvements that will
> make people want to use it. Making it easier to code than HTML 4 will
> ensure a quicker and wider acceptance.
The goal isn't wide acceptance, the goal is a higher quality language.
> I am okay with the unimaginative numbering of the extra elements, as it
> would make it easy to have a lot of new elements. However, there are
> countless possibilities: , , , ,
> , , , , etc...
Well, we have amd now, for sections and figures
respectively.
> Are there other people who have found themselves wishing for another
> or -like tag?
Apparently not. :-)
On Tue, 1 May 2007, Alexey Feldgendler wrote:
>
> HTML is a language for markup meaningful by itself, not just as a hook
> for CSS. doesn't mean anything.
Indeed.
On Tue, 1 May 2007, Jon Barnett wrote:
>
> If you're marking up stuff as a tree, the markup should probably look like a
> tree:
> First group
> Second Group
> Third Group
>
>
>
> if what you want it a tree, that structure is better, so the CSS would
> simply say:
> #tree, #tree div { margin-left: 5em; }
>
> If you want to style each level differently, that's still easy to do without
> making up class names:
> #tree { background: blue; }
> #tree > div { background: green; }
> #tree > div > div { background: yellow; }
Indeed. One could also use nested s for a tree.
On Tue, 1 May 2007, Brenton Strine wrote:
>
> That doesn't seem very practical to me. If all HTML tags imply some
> meaning, then you are advocating the elimination of presentation, not
> it's separation. If there weren't any CSS hooks, wouldn't people just
> (incorrectly) use other tags, like ? I think that CSS and HTML are
> unbreakably connected.
You can hook CSS to the meaning, it doesn't have to be an explicit hook.
For example, you can style your headings:
h1 { color: blue; }
...and the first paragraph after a heading:
h1 + p { text-indent: 2em; }
...and so on.
On Tue, 1 May 2007, Dan Dorman wrote:
>
> An HTML document ought to make semantic sense, without regard to
> presentational information. The very definition of the separation of
> presentation from content is that the content should be authored without
> regard to how it will appear. That's not to say presentation is being
> eliminated, however; presentation simply should not be a consideration
> in how the content is authored. Ideally, anyway.
Indeed.
> Indeed, one could say CSS is fundamentally dependent on HTML; the
> reverse is not true. Imagine a new technology came along to make HTML
> pretty: wouldn't it be nice if you didn't have to rewrite the HTML to
> service this new technology?
Indeed,
> As to folks using incorrect tags, well, what you're proposing isn't
> going to fix that.
Sadly true.
> I think the supposition that multiple class names are confusing is
> flawed. What's wrong with saying
> (besides the fact that you'd want more useful, informative class names
> than "redtext" and "indentmore")? By looking at it, someone could
> readily tell it's got the properties of both "redtext" and "indentmore".
> In my estimation, being able to combine classes is one of the more
> powerful aspects of CSS.
I agree (modulo those class names being poor choices).
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+
Re: [whatwg] Semantic use of the element
On Thu, 12 Apr 2007, Nicholas Shanks wrote: > > I have a website which discusses typography, web design, and computer > fonts. It recently occurred to me that my use of spans with style > elements was not really the most semantic method of getting across my > meaning, and I would be better using the font element. > > My content goes something like this: > > This is a sample of Helvetica > This is a sample of Arial > > Which loses its visual meaning if the CSS is stripped, overridden, or > not understood, and further more I cannot supply fallback fonts (since > that would create a misleading visual appearance) and so here contradict > the CSS guidelines for the font-family property. Would it not be more > correct to use: > > This is a sample of Helvetica > This is a sample of Arial > > In this instance I am saying to the browser that the font is the > critical part of that run of text, and the fact that doesn't > support fall-back works in my favour here, as well as the usage being > fully compatible with graphical UAs. I would argue that HTML is the wrong language for what you're trying to do. What you're conveying is intrinsically visual (media-specific) and you should use a media-specific format, like PDF. Indeed, this point was then put forward by a number of people: On Thu, 12 Apr 2007, Brady J. Frey wrote: > [...] On Thu, 12 Apr 2007, David Walbert wrote: > [...] On Thu, 12 Apr 2007, gary turner wrote: > [...] On Thu, 12 Apr 2007, Bill Mason wrote: > [...] On Thu, 12 Apr 2007, Dave Singer wrote: > [...] HTH, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] lang versus xml:lang
On Mon, 5 Mar 2007, Anne van Kesteren wrote: > > I start to think that lang="" should also be allowed in XML documents. > xml:lang is nice, but if you don't have knowledge of the HTML namespace > knowing the language of certain constructs isn't that valuable. It would > also make HTMLElement.lang useful for XML documents... > > (And user agents have to support and support this stuff already too.) On Mon, 5 Mar 2007, Simon Pieters wrote: > > If lang="" in text/html will still be in the null namespace, then I > agree. I hesitate to do this for the same reason we don't have in HTML -- it is stomping on XML-native mechanisms for the same thing. I'd rather not have people who use XHTML stomping all over the XML-native solutions; it sets a bad precedent and defeats many of the advantages of XML in the first place. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] switch element
On Sat, 15 Apr 2006, Henri Sivonen wrote: > > Is there a reason why the switch element accept any block content and > instead of accepting just section elements? If section is the only > element with the suitable DOM interface, wouldn't it make sense for the > content model to be zero or more section elements one of which (if > non-zero sections) must have the active attribute set? Fixed this by switching to using "irrelevant" instead. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] HTML5 Parsing spec first draft ready
On Tue, 30 Oct 2007, Krzysztof Żelechowski wrote: > > > > > > Because lang in no namespace is what is normal for HTML. However, > > > since Anne said UAs have already implemented xml:lang taking > > > precedence, I guess it is best to go with what is implemented. > > > > Well, xml:lang is what is normal for XML, so why make lang="" beat > > it...? > > This should happen in HTML mode only, XML documents would not be > affected. (I would say xml:lang should be altogether ignored for HTML). We're trying to keep the processing model differences down to a minimum. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Element
On Tue, 30 Oct 2007, Krzysztof Żelechowski wrote: > > Do EM elements accumulate? They are idempotent under the default style > sheet because you cannot make an italic typeface more italic. But do > they accumulate in principle? If they do, is the default style sheet > correct with respect to the EM element? The spec says they do. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] HTML5 Parsing spec first draft ready
Dnia 30-10-2007, wto o godzinie 09:34 +, Ian Hickson napisał(a): > On Sun, 12 Mar 2006, Henri Sivonen wrote: > > > > Because lang in no namespace is what is normal for HTML. However, since > > Anne said UAs have already implemented xml:lang taking precedence, I > > guess it is best to go with what is implemented. > > Well, xml:lang is what is normal for XML, so why make lang="" beat it...? This should happen in HTML mode only, XML documents would not be affected. (I would say xml:lang should be altogether ignored for HTML). Chris
Re: [whatwg] , , , ; Re: Presentational elements in Web Applications 1.0
Dnia 30-10-2007, wto o godzinie 08:33 +, Ian Hickson napisał(a): > (I strongly feel that there is a difference between used for > grouping thematically related blocks, and used for separating > thematically related inline content, e.g. parts of a form. I want to make > inline-in- non-conforming in the case where could better be > used, but without making it non-conforming when it is being used to make > custom widgets. I don't really see what to do about this. Maybe only > allow to contain blocks or elements (but not both)?) It would also clean up the current situation where the strictness of the BODY element is meaningless because you can wrap all content in a DIV element to make it strict. > On Tue, 17 Jan 2006, Eugene T.S. Wong wrote: > > > > I guess I should have looked up the dictionary definition earlier on. I > > just looked it up now, and 1 of the definitions for "title" is "a > > general or descriptive heading for a section of a written work". I was > > wrong. If we look up "heading", we can see the same idea. I must say > > that I'm pretty surprised. I've never heard of anybody using "heading" & > > "title" interchangeably, outside of HTML. > > I don't know what the difference would be if they're not the same. :-) If the written work is a composition, it would have a title; if it is ephemeral excerpt, like a note, a notice or a memo, it would have a heading. That is my intuition; I may be wrong because I did not attend an English school. Cheers, Chris
Re: [whatwg] Element
Dnia 30-10-2007, wto o godzinie 08:47 +, Ian Hickson napisał(a):
> On Sat, 14 Jan 2006, Lachlan Hunt wrote:
> >
> > No, you're using a presentational element where a suitable semantic
> > element already exists. It is irrelevant that it doesn't have the
> > default styling that you want from big, but that can be handled with
> > CSS. That example should be marked up like this:
> >
> > I said, "NO!".
> > YES!! I will do it!
> > NO! You will not!
> > YES!! I will do it!
> > NO! You will not!
> > YES!! I will do it!
> > NO! You will not!
> > Oh, alright...
> >
> > em { font-size: larger; }
>
> Indeed.
>
Do EM elements accumulate? They are idempotent under the default style
sheet because you cannot make an italic typeface more italic. But do
they accumulate in principle? If they do, is the default style sheet
correct with respect to the EM element?
Intriguedly,
Chris
Re: [whatwg] HTML5 Parsing spec first draft ready
On Sat, 11 Mar 2006, Henri Sivonen wrote:
> On Mar 11, 2006, at 03:20, Ian Hickson wrote:
> > On Sun, 19 Feb 2006, Henri Sivonen wrote:
> > >
> > > Off the top of my head, the changes from the HTML parsing output
> > > involve (besides lowercasing names and putting elements in the XHTML
> > > 1.x namespace) getting rid of the meta element conveying character
> > > encoding information,
> >
> > Why? It doesn't need to be removed, it just has no semantics in XHTML.
>
> The spec says that it may be used that way only in HTML. Therefore, an
> algorithm that maps conforming HTML5 to conforming XHTML5 must remove it
> in order to keep the result conforming.
Yes, you're right.
> > > mapping the lang attribute to xml:lang
> >
> > "lang" is still valid in XHTML.
>
> Not according to the spec. It says "lang (HTML only) and xml:lang (XML
> only)". (I like it the way it is with only one language attribute on
> each side.)
Yeah, also right.
> BTW, the spec also says: "If both the xml:lang attribute and the lang
> attribute are set, user agents must use the xml:lang attribute, and the
> lang attribute must be ignored for the purposes of determining the
> element's language."
>
> Shouldn't lang take precedence in HTML?
Apparently not based on existing implementations.
On Sun, 12 Mar 2006, Henri Sivonen wrote:
>
> Because lang in no namespace is what is normal for HTML. However, since
> Anne said UAs have already implemented xml:lang taking precedence, I
> guess it is best to go with what is implemented.
Well, xml:lang is what is normal for XML, so why make lang="" beat it...?
On Sat, 11 Mar 2006, Anne van Kesteren wrote:
>
> I'd be opposed to that. At least two UAs have implemented the opposite.
> ("xml:lang" taking precedence over "lang".)
That's a convincing argument...
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Full screen for the element
On Tue, 30 Oct 2007, Dave Singer wrote: > > I think if you can collect keystrokes then phishing is also on the > cards, alas. True. > > > 2. It's not clear what would be the best way for UAs to provide the > > > functionality while preventing sites from taking advantage of the > > > feature and annoying users. > > > > Both, and also that it's considered ok for the user to have to tell > > the UA that he wants to go fullfreen (rather than the script having to > > tell the UA that the user wants to go fullscreen). > > I think there's both demand and precedent; and if it's not in the > spec., as I say, it should be explicitly excluded with its reasons, so > browser makers don't simply all add it as an extension. That way, we'd > get all the problems again, plus an interoperability problem as well. Good point. Added a note. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Attributes, namespaces and language determination
On Mon, 23 Jan 2006, Simon Pieters wrote: > > Looking at how to determine the language of a node[1]: > > > To determine the language of a node, user agents must look at the nearest > > ancestor element (including the element itself if the node is an element) > > that has a lang or xml:lang attribute set. That specifies the language of > > the node. > > ...and terminology[2]: > > > Unless otherwise stated, all elements defined or mentioned in this > > specification are in the http://www.w3.org/1999/xhtml namespace, and all > > attributes defined or mentioned in this specification have no namespace > > (they are in the per-element partition). > > ...it could be interpreted that the language of the text "foo" in the > following document is "x": > > http://www.w3.org/1999/xhtml";>foo > > ...which is probably not what was intended. > > [1] http://whatwg.org/specs/web-apps/current-work/#lang > [2] http://whatwg.org/specs/web-apps/current-work/#terminology Fixed. Thanks. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Element
On Fri, 13 Jan 2006, Eugene T.S. Wong wrote:
>
> Hi again. Are tired of reading my emails yet? ;^P Please don't answer
> that question!! ;^)
>
> I noticed that there is a element, but no element. Is
> there a specific reason for this?
Indeed there is, as Lachlan almost immediately pointed out:
On Sat, 14 Jan 2006, Lachlan Hunt wrote:
>
> Both of them are quite presentational, but there is an attempt to
> redefine the small element with some semantic meaning. The same cannot
> be said for big, it is (and probably always will be) presentational, and
> therefore has no place in a semantic markup language.
Not much I can add to that.
On Fri, 13 Jan 2006, Eugene T.S. Wong wrote:
>
> & are presentational as well.
Actually both are redefined to be media-independent in HTML5.
> > but there is an attempt to redefine the small element with some
> > semantic meaning.
>
> If that is true, then I encourage the WHATWG to use another name, such
> as ASDF. It is a lot longer, but it does convey
> more semantics.
As was pointed out in the original thread, the name doesn't convey
semantics, the element and its definition do.
> A semantic markup language can't possibly have every single type of
> semantic out there. There are some cases that are so rare, that it would
> be a waste to define them.
Certainly.
> Sometimes really does convey something. For example:
>
> I said, "NO!".
> YES!! I will do it!
> NO! You will not!
> YES!! I will do it!
> NO! You will not!
> YES!! I will do it!
> NO! You will not!
> Oh, alright...
As was later pointed out, is the appropriate element here. Shouting
is an extreme kind of stress emphasis.
> I suppose that you could argue that CSS would create the same effect,
> but you shouldn't have to use CSS to create the effect of a shouting
> match. Besides, those words would have to be surrounded by elements,
> anyways, so it wouldn't hurt to use an element that has a default style.
> There is nothing wrong with using a non-semantic element that has a
> default style as opposed to YES.
There is one problem, which is that user agents incapable of showing the
original element's default style (e.g. a text mode browser with no font
size control, or a speech browser, or a braille browser) has no guidance
as to what to do with the contents. On the other hand, using a semantic
element like allows the user agent to intelligently substitute the
original recommended rendering with an equivalent rendering that it can
render on its medium.
> The problems of the past arose because:
>
> 1) people used the wrong semantic elements
> 2) people used non-semantic elements where there were semantics
>
> In the above scenario, there are semantics, but there are no semantic
> elements to convey shouting.
I disagree; is appropriate here.
> The elements are modifiable by CSS. I suppose that we could nest
> a few times, but I don't recognize strong emphasis as the same
> thing as shouting.
in HTML5 represents importance, so I agree that it is not
appropriate here.
> Also, it might be helpful to use for math problems, without having
> to resort to MathML.
Mathematics are indeed a thorny problem. It's unclear that would go
far enough in solving it though.
On Sat, 14 Jan 2006, Lachlan Hunt wrote:
>
> No, you're using a presentational element where a suitable semantic
> element already exists. It is irrelevant that it doesn't have the
> default styling that you want from big, but that can be handled with
> CSS. That example should be marked up like this:
>
> I said, "NO!".
> YES!! I will do it!
> NO! You will not!
> YES!! I will do it!
> NO! You will not!
> YES!! I will do it!
> NO! You will not!
> Oh, alright...
>
> em { font-size: larger; }
Indeed.
On Fri, 13 Jan 2006, Eugene T.S. Wong wrote:
>
> As I've already said, doesn't convey shouting. How much less
> would convey shouting? The answer is "much less"!
In HTML5 and are orthogonal in definition.
On Sat, 14 Jan 2006, James Graham wrote:
>
> Although the HTML5 spec does admit a small number of elements of
> questionable semantics (at least historically - they have mostly been
> redefined to have non-presentational meanings) it is only the elements
> that are in wide use and address a use-case that is not already covered
> by another element that have received this special treatment.
> was eligible because it is very commonly used for a single purpose and
> the definition of small as "(legal) small print" basically makes sense.
> does not get the special treatment because there is no use case
> that isn't covered by CSS, and .
Right.
On Sun, 15 Jan 2006, Anne van Kesteren wrote:
>
> It does not. The "semantics" of an element are bound to the definition
> of it, not to the name.
Indeed.
> I think nested elements are in order here. You don't really need
> for that. does not represent "shouting" in any definition
> I've seen so far and comes pretty close as
Re: [whatwg] , , , ; Re: Presentational elements in Web Applications 1.0
On Fri, 13 Jan 2006, Eugene T.S. Wong wrote:
>
> I'd like to recommend that the WHATWG bring back because it
> provides an excellent way of saying "this is a centered ". is
> no more semantic that , , or , yet they have their uses.
Based on the arguments given in this thread (the bulk of which are quoted
below) I have concluded that we should not include in the HTML5
language. However, it will be defined in the rendering section in due
course, and will continue to work in browsers for the forseeable future.
> I'd like to recommend that the WHATWG bring back & , because
> these elements have semantic meaning and don't significantly affect how
> the list is presented. The lack of significant effects means that the
> legacy browsers will still be able to make use of the elements. The good
> thing about creating more semantic list elements, is that they create a
> greater diversity, standardization and detail, without requiring
> enhancements to UA technology. You could make any type of a list and it
> would work. The default styling may not be what you want, but it would
> work.
is reintroduced for context menus and toolbars.
at this point is basically redundant with , so should
probably continue to be omitted, so as to not give too many mixed messages
(HTML4 deprecated it, so reintroducing it now without substantial
improvements or strong reasons would just be confusing).
> I'd like to recommend that the WHATWG standardize . I suggest this
> because is shorter than and because is consistent with
> XHTML. As I typed the previous sentence, I noticed that is much
> easier to type with 1 hand, than .
Assuming you mean XHTML2's , you can achieve the same results
in HTML5 using , in a way that is backwards
compatible with legacy user agents.
On Sat, 14 Jan 2006, Lachlan Hunt wrote:
>
> No, center is presentational, div is not. Authors should not use
> presentational markup, regardless of how much easier it seems. In fact,
> the easier method is to increase the amount of semantics, increase you
> knowledge of and skills with selectors so you don't have to use a class
> for everything, and style based on the elements semantics.
>
> What's wrong with:
>
> Resume h1 { text-align: center; }
Indeed.
On Sat, 14 Jan 2006, Rob Mientjes wrote:
>
> And just for the record, DIV is structural markup, which is allowed and
> even encouraged if you have a complex, er, structure.
I'm not sure I'd say it's encouraged, but yes.
On Tue, 17 Jan 2006, Eugene T.S. Wong wrote:
>
> Here is an example that I'm working on now. I'm trying to make a
> flyer/brochure to hand out to businesses after talking to them. I hope
> that they will consider giving me merchandise to use as prizes for a
> poker club that I'm trying to start. There is absolutely no intent for
> me to post this on the web. I may do that in the future, but definitely
> not in the foreseeable future. The content is changed, but hopefully
> it'll make sense.
For non-Web publishing, I would strongly recommend investigating in a
more appropriate technology such as Open Office Writer, Pages, or Word.
> I refuse to use as a title, based on my own principles that there
> can be only 1 title, just as there can be only 1 document root. There
> can be multiple headings, but not mulitiple titles for each document.
HTML5 explicitly allows multiple elements. You could also use .
On Tue, 17 Jan 2006, Simon Pieters wrote:
>
> There is a element type for this purpose. Use the following CSS:
>
> head { display:block; text-align:center; }
> title { display:inline; }
...or this, indeed.
On Sun, 15 Jan 2006, Matthew Paul Thomas wrote:
>
> is presentational: it means "present this as a block". That is
> what it will mean in HTML 5 documents as well, regardless of how it is
> eventually defined in the specification, because author momentum will be
> too great to usefully narrow its meaning. And that's okay: there is no
> evidence that any deity kills a kitten when someone uses .
There's an open issue on exactly what to do with , but yeah.
> Authors should use presentational markup whenever there is no available
> semantic markup for the relevant meaning, or when they are providing
> authoring facilities for people who cannot be expected to think about
> semantic markup (e.g. people using Webmail, or people posting comments
> on the author's Weblog). If authors -- or specifications -- try too hard
> to use a semantic element, or to force other people to use it, it will
> be misused so much that UAs can no longer trust the element to have any
> particular meaning, so it will become de facto presentational.
True... but it's not clear if elements like and are the
best way of addressing this.
>
> This was defined in HTML 3.0 and 3.2 to mean about the same as
> means in Web Applications 1.0, but was soon repurposed by
> Web authors for any block for which the author coul
Re: [whatwg] Full screen for the element
At 5:47 + 30/10/07, Ian Hickson wrote: > > Also, if the setting exists, it's far easier to trick users into > setting it than if it doesn't. Out of curiousity, is an automatic switch to full screen without the user's consent considered an annoyance/usability problem or a security/fishing attack/vulnerability problem or both? FWIW, it's only the former IMO. The former, yes. I think if you can collect keystrokes then phishing is also on the cards, alas. > If someone does ask why scripts can't switch to full screen, what would the reason(s) be? 1. There doesn't seem to be much demand for it. 2. It's not clear what would be the best way for UAs to provide the functionality while preventing sites from taking advantage of the feature and annoying users. Both, and also that it's considered ok for the user to have to tell the UA that he wants to go fullfreen (rather than the script having to tell the UA that the user wants to go fullscreen). I think there's both demand and precedent; and if it's not in the spec., as I say, it should be explicitly excluded with its reasons, so browser makers don't simply all add it as an extension. That way, we'd get all the problems again, plus an interoperability problem as well. -- David Singer Apple/QuickTime
