Re: [whatwg] SPOOFED: Re: SPOOFED: Re: ---
On Wed, Nov 5, 2008 at 6:29 AM, Pentasis [EMAIL PROTECTED] wrote: I am not sure whether I understand you correctly... Of course the practical use of a specification lies in its technical implementations, or do you disagree with that? You are free to specify your own markup language, but it will be useless if there is no kind of mechanism to interpret the documents marked up that way. So I don't understand how the technical side could be split away. Strictly speaking, does it matter for the DOM or parser or whatever, if a tag is named and used like: abbr title=descriptionsomeword/abbr or like this: reference class=abbreviation ttle=some descriptionsomeword/reference. I don't see how that would make things technically different? The same applies for the difference in (for example) codeblabla/code or p class=codeblabla/p. It matters in the sense that web browsers would have to implement both approaches for backwards compatibility. Web site developers would then be given a choice between a succinct approach that works in all browsers and a verbose approach that only works in the newer ones. Given such a choice, web site developers mostly prefer brevity and compatibility, especially when working for a client. Any change that tries to replace an existing feature with a more complicated feature will likely not be adopted de facto, even if it is enshrined in a de jure standard. Standards that have tried to make changes like that -- XHTML2 comes to mind -- have not been as successful as HTML4, as the loose dialect of HTML4 in use on the web. HTML5 aims to be as successful as HTML4. Adoption and usability are the twin goals -- not purity or consistency. This works everywhere and is brief: abbr title=descriptionsomeword/abbr This would only work in new browsers and is wordy: reference class=abbreviation ttle=some descriptionsomeword/reference. It doesn't add any extra information. It's harder to use. Conceptually, it may be more elegant, but conceptual elegance is not an impetus for large scale adoptions. In my opinion, it is not a worthwhile change to pursue, when there are so many actively broken issues that can be fixed. Regards, Leons Petrazickis http://lpetr.org/blog/
Re: [whatwg] native styling for search input boxes
On Wed, Oct 1, 2008 at 1:04 PM, Kristof Zelechovski [EMAIL PROTECTED] wrote: Please give some examples how the special status of a search field can be used by user agents, presentation aside. (I am not trying to challenge Matthew's argument, I am just interested). Chris Firefox, IE8, and several other browsers allows for search provider autodiscovery. When they encounter a site with a specific link tag, their searchbox dropdown lights up, denoting that the site can be added as a permanent search target. http://www.rebron.org/2006/06/01/search-discovery-in-firefox-20/ http://msdn.microsoft.com/en-us/library/cc848862(VS.85).aspx A special search field could also integrate with this facility in a more automatic and natural way. Any site with marked-up search field could be considered a search provider. Regards, Leons Petrazickis http://lpetr.org/blog/
[whatwg] Pagination Was: article: do we really need this?
On 2/21/08, Ian Hickson [EMAIL PROTECTED] wrote: I think it is likely blog templates will use it correctly most of the time, which would cover many uses of this element. I think the use cases for section and article are quite distinct, and that trying to merge them would hurt both elements on the long run. Has pagination been addressed? Would the suggested way to mark up this: [ 1 ] [ 2 ] [ 3 ] [ 4 ] ... or this: First Prev 1 2 ... 30 31 Next Last be a ul in a nav element? Also, I am not sure what the overall page markup would be. article requires a stand-alone document, while section is more generic but gives chapters as an example usage. Option 1: article id=page2 Lorem ipsum. navul id=pagination.../ul/nav /article Option 2: section id=page2 Lorem ipsum. navul id=pagination.../ul/nav /section Option 3: article section id=page2 Lorem ipsum. navul id=pagination.../ul/nav /section /article Is any of these options the recommended one? Regards, Leons Petrazickis http://lpetr.org/blog/
Re: [whatwg] SQL API + access to tables
You need the ability to list tables for integration with tools such as Firebug. Apple is adding table introspection to Safari's equivalent of Firebug. How should Firebug or some other third-party tool achieve it? Regards, Leons Petrazickis http://lpetr.org/blog/ On 10/20/07, Křištof Želechovski [EMAIL PROTECTED] wrote: To achieve what? To make spying and breaking easier? The developer should know the structure of the database in advance; making such guesswork in production code on the end user's machine is at least inappropriate. Also, if we agreed to that, this would be a workaround for a supposed deficiency of SQL. But the SQL committee does not recognize it as a deficiency; otherwise it would have been fixed by now. Best regards, Chris -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brady Eidson Sent: Saturday, October 20, 2007 3:14 AM To: WHATWG Mailing List Subject: [whatwg] SQL API + access to tables There is no standard way in SQL that I know of to get the list of tables in a database. In SQLite you can enumerate tables out of sqlite_master, but that should not be encouraged. What are people's thoughts about adding this to the API? ~Brady
Re: [whatwg] hashchange only dispatched in history traversal
On 8/15/07, Michael A. Puls II [EMAIL PROTECTED] wrote: On 8/14/07, Ian Hickson [EMAIL PROTECTED] wrote: On Sat, 11 Aug 2007, Michael A. Puls II wrote: I like hashchange even if it's not perfectly descriptive. However, fragmentidentifierchange although long, isn't much longer than DOMAttributeModified and is shorter than say, DOMNodeRemovedFromDocument. addEventListener(fragmentidentifierchange doesn't seem too bad to me. And, if for some reason you wanted it shortened in your script, you could just do: var hashchange = fragmentidentifierchange; a.addEventListener(hashchange b.addEventListener(hashchange c.addEventListener(hashchange I don't know. body onfragmentidentifierchange= ...seems a bit overly long to me, still. True. As an attribute with the on part, it looks pretty bad. I've always referred to fragment indentifiers as in-page anchors. So, why not: body onanchorchange= I think it's more readable than onfragmentidentifierchange There is an HTMLCollection anchors that only lists a name= elements. Extending the link-anchor metaphor into Javascript, the fragment identifier anchors a DOM state. When a fragment identifier changes, the anchor of the DOM state changes. Regards, Leons Petrazickis Database Technology Advocate, IBM http://lpetr.org/blog/
Re: [whatwg] The m element
On 2/6/07, Alexey Feldgendler [EMAIL PROTECTED] wrote: On Tue, 06 Feb 2007 09:13:27 +0100, Mikko Rantalainen [EMAIL PROTECTED] wrote: Perhaps m should be considered as a special case of em. I would have to agree that semantic value of m over em is next to meaningless. I think that one usable definition between m and em would be that m is meant for highlighting content for a single user and em is meant for emphasizing stuff in general. That would limit usage of m to dynamically generated content only, though, and reserving such a short tag for that purpose only doesn't seem reasonable. IMO, the key difference between m and em is that m is intended to be placed by somebody or something other than the author of the original text. This distinction may be too fine for people to follow. It's reminiscent of the rev VS rel distinction, which few people grasped. Regards, -- Leons Petrazickis Database Technology Advocate, IBM I work on the free DB2 Express-C database http://www-306.ibm.com/software/data/db2/express/
Re: [whatwg] blockquote cite and q cite
On 1/19/07, Benjamin Hawkes-Lewis [EMAIL PROTECTED] wrote: Henri Sivonen wrote: My point was that BibTeX/LaTeX/TeXlipse users are already receptive to the idea that they have to provide rich metadata for citations, so a UI test would not be a matter of testing *if* they provide the data but about *how* they like to provide it. Oh I see: you mean whether people prefer entering ISBNs or typing out all the metadata by hand? Why isn't LibraryThing already a good test that shows that people like to use ISBN lookup? And given the lookup can work either way (from book details to ISBN or from ISBN to details), what exactly would it mean if 2/3 were masochists who prefer hand entry of book details? On LibraryThing, I use book title or sometimes author + book title. I only pull out ISBN for disambiguation with old books that have too many editions, but where I want the right cover to show up. ISBN is not an intuitive concept. It's like being asked your account number when you call your tech support. You want them to look you up by name, address, phone number, or virtually anything else but unique account number -- account numbers should be relegated to the inside of databases and exposed only in exceptional cases. Account numbers are not human-readable. Neither are ISBN. You can't proofread them for typos, and search engines can't error-correct mistyped ISBNs the way they can for mistyped authors and mistyped titles. I have nothing against citing by ISBNs, but if I ever cite, it will be by book title and author, by movie title and director, by song title and singer. HTML5 can support both, but it should at least support the latter. -- Leons Petrazickis
Re: [whatwg] contenteditable, em and strong
On 1/9/07, Henri Sivonen [EMAIL PROTECTED] wrote: My conclusion is that semantic markup has failed in this case. em and i are both used primarily to achieve italic rendering on the visual media. strong and b are both primarily used to achieve bold rendering on the visual media. Regardless of which tags authors type or which tags their editor shortcuts produce, authors tend to think in terms of encoding italicizing and bolding instead of knowingly articulating their profound motivation for using italics or bold. Even those who have heard about the theoretical reasons for using em and strong tend to decide which one to use based on which one has the preferred default visual presentation for the case at hand. A more general question is whether bold or italic are presentational. Are they any more presentational than capitalizatio?. Methinks the assumption that capitalization is semantic while bold and italic are presentational is a historical accident, not reality. Imagine a world where ASCII only had lowercase characters. A different font would have to be substituted for uppercase, just as a different font now has to be substituted for italic or bold. A web browser in such a world would have this presentational tag: capitalize - Capitalizes the first letter of every word And these semantic tags: sentence - By default, capitalizes the first letter of the first word. proper - By default, capitalizes the first letter of every word. CSS would show up, and the semantic markup philosophy would catch on. Adherents would proclaim capitalize Considered Harmful and urge people to switch to sentence for sentences, proper for proper nouns, and CSS spans for other uses. After all, different languages, different dialects, different cultures all have different capitalization practices. Different publishing houses capitalize titles differently. Instead of doing that, people just swapped proper in place of capitalize. The adherents raged. What fools these people be. The first word of a sentence is not a proper noun. We need to proselytize more! But to no avail. *** Capitalize, b bold, and i italicize are all intrinsic properties of prose, just as br line breaks are intrinsic properties of poetry. They can be abused: divpbfont size=+4Dragons Be Here/b/div/p/font But using them mid-paragraph is not abuse. Their use should be neither deprecated nor discouraged. -- Leons Petrazickis
Re: [whatwg] Semantic styling languages in the guise of HTML attributes.
On 12/20/06, James Graham [EMAIL PROTECTED] wrote:
Matthew Raymond wrote:
A semantic styling language would be a language to assign semantics
to elements in a manner similar to how CSS controls their presentations.
FWIW, it seems that a better term for the concept you describe would be
semantic binding language, since presentation isn't actually involved
anywhere. In the same vein CSS would be a presentation binding language and
XBL roughly a behavior binding language. Having said that, I'm not sure I
follow the point that you are trying to make.
I think what's wanted is a Cascading Semantics Language. Its syntax
could be based on CSS. For example:
.masthead {
type:heading;
strength:high;
}
.division {
type:heading;
strength: normal;
}
.flow {
type:body;
strength:normal;
}
.aside {
strength:weaker;
}
Behaviours, script bindings, etc could be mixed into this.
Regards,
--
Leons Petrazickis
Re: [whatwg] Allow trailing slash in always-empty HTML5 elements?
On 11/30/06, Sam Ruby [EMAIL PROTECTED] wrote: On 11/30/06, Anne van Kesteren [EMAIL PROTECTED] wrote: It has to allow two authoring syntaxes. One HTML and one XML. I thought we were past that discussion? The sense I am gathering is that the proposal is not obviously insane, and in fact is a bit novel in that such a narrowly scoped adoption of XML syntax -- i.e., only to the extent that it both reflects the web as widely practiced and only to the extent that doing such does not introduce ambiguity into the grammar -- had not been considered before. In any case, I plan to proceed on the assumption that it is worth my time to flesh out the proposal a bit more. The next iteration is likely to also contain thoughts on extensibility and namespaces. Like this proposal was, my intent is that that proposal too will also take great care to only be minimally invasive. So far, the proposal is to have two syntaxes: 1) HTML5 - Backwards-compatible text/html syntax that allows trailing slashes on always-empty elements. 2) XHTML5 - Full XML syntax with the proper mime type. I am not sure where extensibility and namespaces would fit into that. Perhaps they should be proposed independently of this. Again, early adopters of CSS, validation, and semantic mark-up were told a story. That story said that maintainability=no formatting in HTML=CSS=XHTML=trailing backslashes on empty elements. That's not true, but quibbling nets few converts. If we make trailing backslashes invalid, then every bug report we file will say: - Remove trailing backslashes. You can't serve XHTML like this. That will invariably be rejected. If we keep them valid on always-empty elements, then it'll be much nicer: - HTML5 is the new hot thing. You shouldn't be serving XHTML as text/html anyways. Switch doctypes, revalidate, and iteratively improve markup It's much easier to gain acceptance, agreement, buy-in, consensus on the latter. The validation errors they'll see will actually help them with browser compatibility. -- Leons Petrazickis
Re: [whatwg] Joe Clark's Criticisms of the WHATWG and HTML 5
On 10/31/06, Charles Iliya Krempeaux [EMAIL PROTECTED] wrote:
Hello,
On 10/31/06, Rimantas Liubertas [EMAIL PROTECTED] wrote:
...
To get valid markup I must use a table tags if I want my layout to
*function* that way. There is no way to fake it. It took three minutes
to change the tags to table tags and the page functions perfectly now.
This is for the benefit of the users.
Some case of non sequitur, imho.
I am in ban tables for layout camp. If anyone want to use them for
this purpose
they are free to use some other standard or do not use any standard at
all...
Weren't we talking about creaing new HTML elements for a grid layout before?
(Or am I dreaming?)
What ever happened to that?
The Dojo Javascript Toolkit (http://dojotoolkit.org/) has excellent
several excellent layout widgets, including a grid layout achieved
with proprietary attributes. I used it for an intranet web
application, and it's very intuitive. For example:
div dojoType=LayoutContainer layoutChildPriority=none
div dojoType=ContentPane layoutAlign=left
left
/div
div dojoType=ContentPane layoutAlign=top
top bar
/div
div dojoType=ContentPane layoutAlign=bottom
bottom bar
/div
div dojoType=ContentPane layoutAlign=left
inner left
/div
div dojoType=ContentPane layoutAlign=right
inner right
/div
div dojoType=ContentPane layoutAlign=client
This is the main panel. It expands to fill all the left-over
space
after placing all the top/bottom/left/right panels.
/div
/div
Take a look on the website. It's under See it in Action Layout
LayoutContainer. The demos are broken in Opera because of stupid site
design.
A straight conversion to tags is even clearer, but might be too presentational:
container
pane layout=leftouter left/pane
pane layout=toptop bar/pane
pane layout=bottombottom bar/pane
pane layout=leftinner left/pane
pane layout=rightinner right/pane
pane layout=clientremainder/pane
/container
So we could move it to CSS, though that may present difficulties in
simulating browser compatibility via Javascript:
#container { layout-type: grid; }
#navbar{ layout-position: left; }
#masthead { layout-position: top; }
#footer { layout-position: bottom; }
#sidenotes { layout-position: left; }
#sidelinks { layout-position: right; }
#text { layout-position: client; }
div id=container
div id=navbarouter left/div
div id=mastheadtop bar/div
div id=footerbottom bar/div
div id=sidenotesinner left/div
div id=sidelinksinner right/div
div id=textremainder/div
/div
Again, you can stuff as many lefts, rights, and so ons in as you want.
It's like the inverse of an onion. The order in the CSS file
determines what's on the outside and what's on the inside.
Having made many CSS layouts by hand and having also used the Dojo
implementation, I have to say that this is a degree of magnitude
easier. A few lines of code sets up the whole layout without having to
worry about the arcanes of floating, widths, z-order, relative vs
absolute, and so on.
Regards,
--
Leons Petrazickis
http://lpetr.org/
