Rohan Prabhu wrote:
i was just wondering, that in the Web Controls 1.0 specifications, in
the psuedo classes specifications, could it be that the psuedo classes
could also be the DOM Events which would modify the style information
attached to it. Like for ex:
#objectid:onmouseup
On Thu, 30 Nov 2006 03:42:38 +0600, Sam Ruby [EMAIL PROTECTED] wrote:
What should be the most damning of all is that I found an example on the most
prominent page on the mozilla.org site. No one can say that the authors of
that page didn't make a conscious choice in the DOCTYPE for that page.
Henri Sivonen wrote:
Are you saying that you don't believe the ecosystems around those
languages to be capable of producing HTML5 parser libraries or are you
saying that programmers wouldn't use the libraries even if the ecosystems
produced them?
The biggest problem (80%) is they won't use them
I've just started (today) a .NET implementation (in C#):
a parser as an XmlReader subclass and writers as XmlWriter
and HtmlTextWriter subclasses.
What license will you release under? Can this implementation (and others)
be hosted somewhere that people would be willing to include in the
Elliotte Rusty Harold:
For a long time we not so deliberately did limit the Web
to people who were comfortable hand editing tags. Then
blogs came along, and changed all that. (Wikis too.)
There's an order of magnitude more people publishing
now than there used to be a few years ago, and
Karl Dubost wrote:
but there's a point that we might take into consideration:
People. People do not want spend time structuring information,
only a minority like me. If the only way to edit structured
document is hand coding then it will fail. Always.
But please don't use the idea of
Mike Schinkel wrote:
The lesser problems (20%) are that it will take time for reasonably good
ones to evolve, and many will be subtly incompatible because of a variety of
reasons: a.) lack of complete understand of the spec, b.) time-to-market
concerns, c.) belief that full compatibility is not
Mike Schinkel wrote:
Microsoft released Expression Web yesterday:
http://www.microsoft.com/products/expression/en/expression-web/features.mspx
The narrator for their video for Standards-based Web Sites says XHTML
builds upon the HTML standard that allows a larger percentage of browsers to
On Sun, 03 Dec 2006 10:00:06 +0600, Mike Schinkel [EMAIL PROTECTED] wrote:
And as I write this email, it's finally come to me one method that would
work for even the most clueless and apathetic of web publishers: What if
Google, Yahoo, and Microsoft Live were to display a human-readable
On Tue, 05 Dec 2006 18:14:19 +0600, Mike Schinkel [EMAIL PROTECTED] wrote:
The spec shouldn't contain references to implementations.
However the wiki should contain such a list (see
http://wiki.whatwg.org/wiki/Implementations ).
Then minimally the spec should at least contain (something
On Tue, 05 Dec 2006 22:30:36 +0600, Lachlan Hunt
[EMAIL PROTECTED] wrote:
A specification cannot refer to something as volatile as a wiki page.
Actually, it's already doing that in another section.
http://www.whatwg.org/specs/web-apps/current-work/#other
I think it's inappropriate there
On Wed, 2006-12-06 at 01:35 +0600, Alexey Feldgendler wrote:
I think it's inappropriate there as well. How can a spec refer to a wiki
page which can be edited by anyone and is, in general, out of sync with
the spec itself?
It seems problematic to me too. In the case of microformats, I'd
I'm back. Sorry for the delay.
Ian Hickson wrote:
On Tue, 5 Dec 2006, Elias Torres wrote:
In one of the products, we need two things: one to specify our own piece
of structure data (call it microformat, call it RDFa data).
Could you give an example of the kind of data you're talking about
On Wed, 6 Dec 2006, Alexey Feldgendler wrote:
A specification cannot refer to something as volatile as a wiki
page.
Actually, it's already doing that in another section.
http://www.whatwg.org/specs/web-apps/current-work/#other
I think it's inappropriate there as well. How can
On Dec 4, 2006, at 11:04 PM, Elias Torres wrote:
If you can read in the uF wiki [1] there's really not much guidance
on how to parse
one or all of them.
There is more documentation than you suggest. See [1], which
documents how to parse hcards. Much of the hCard parsing guideline
apply
There's plenty of documentation/code/test cases for *specific*
microformats but no general rules for let's say additional fields in an
hCard. Let me know if I'm missing any other documentation or overall
principle in microformats.
-Elias
ryan king wrote:
On Dec 4, 2006, at 11:04 PM, Elias
On Tue, 5 Dec 2006, Elias Torres wrote:
[...]
I'm having trouble understanding what you're doing.
Could you provide some actual code examples? They can be fictional, I'm
just trying to work out what you're doing.
For example:
At the moment we have data defined using by XML schemas that
On Dec 5, 2006, at 2:11 PM, Elias Torres wrote:
There's plenty of documentation/code/test cases for *specific*
microformats but no general rules for let's say additional fields
in an
hCard. Let me know if I'm missing any other documentation or overall
principle in microformats.
You're not
ryan king wrote:
On Dec 5, 2006, at 2:11 PM, Elias Torres wrote:
There's plenty of documentation/code/test cases for *specific*
microformats but no general rules for let's say additional fields in an
hCard. Let me know if I'm missing any other documentation or overall
principle in
It would be useful if in section 9.2.4.4. The trailing end phase,
phrases such as Switch back to the main phase and reprocess the token.
linked to the part of section 9.2.4.3.6. The insertion mode that
define which insertion mode the main phase should be in when making this
switch.
--
The
Le 5 déc. 2006 à 17:03, Ian Hickson a écrit :
The one target now is HTML5.
I wonder about one thing though. If the recommended serialization is
HTML5, why is there new features which are simply not supported by
HTML5 (list inside paragraphs, nested forms, etc.)? My impression is
that
On Tue, 5 Dec 2006, Ian Hickson wrote:
p id=order1 class=ibm-order
p
has purchased a
span about=order1 property=ibm-part
The key point here being the reference to an earlier blob in the same
page, right?
Interesting. That's something that currently can
On 12/5/06, Ian Hickson [EMAIL PROTECTED] wrote:
On Tue, 5 Dec 2006, Elias Torres wrote:
p class=ibm-order
span property=ibm-customer
span property=ex-nameIan Hickson/span
(span property=acme-id95237032895/span)
/span
has purchased a
span
On Tue, 5 Dec 2006, Michel Fortin wrote:
The one target now is HTML5.
I wonder about one thing though. If the recommended serialization is
HTML5, why is there new features which are simply not supported by HTML5
(list inside paragraphs, nested forms, etc.)? My impression is that
On Tue, 5 Dec 2006, Elias Torres wrote:
A few comments on your code. You can handle with n-levels deep, but
not really nested property.
Why not? I don't understand. Could you give concrete examples?
You are also assuming that the content of the element is the entire
value of the
On Dec 5, 2006, at 16:07, Thomas Broyer wrote:
2006/12/5, Mike Schinkel:
I've just started (today) a .NET implementation (in C#):
a parser as an XmlReader subclass and writers as XmlWriter
and HtmlTextWriter subclasses.
Cool! I think making the HTML5 implementations drop-in replacements
On Wed, 6 Dec 2006, Henri Sivonen wrote:
Of course, in all these cases, the element names should be reported in
lower case unlike in browsers.
Per HTML5 they're lowercase in browsers too, it's just that .tagName in
the DOM in HTML Web browsers uppercases. (i.e. returning lowercase is not
Le 5 déc. 2006 à 22:44, Benjamin Hawkes-Lewis a écrit :
On Tue, 2006-12-05 at 09:25 +0900, Karl Dubost wrote:
but there's a point that we might take into consideration: People.
People do not want spend time structuring information, only a
minority like me.
(X)HTML is clearly not for people
On Tue, 5 Dec 2006, Sam Ruby wrote:
Case in point:
http://www.intertwingly.net/blog/2006/12/01/The-White-Pebble
In IE, there's some stray XHTML HTML and XHTML HTML XML text. This
isn't acceptable to most people. It certainly isn't something that it
would make sense to
Le 6 déc. 2006 à 11:23, Ian Hickson a écrit :
On Wed, 6 Dec 2006, Karl Dubost wrote:
Interesting. That's something that currently can only really be done
with tables, output, and hyperlinks; I wonder if we should add a
fourth way that is more convenient for Microformat-like data.
And it's
Ian Hickson wrote:
I don't see any documentation that requires XHTML to not support
display.write, but it certainly is a reality that nobody has done so.
http://www.whatwg.org/specs/web-apps/current-work/#document.write1
(I'd like to make it work, but can't work out how to specify it. If
Ian Hickson wrote:
On Tue, 5 Dec 2006, Sam Ruby wrote:
Case in point:
http://www.intertwingly.net/blog/2006/12/01/The-White-Pebble
In IE, there's some stray XHTML HTML and XHTML HTML XML text. This
isn't acceptable to most people. It certainly isn't something that it
would make sense to
Ian Hickson wrote:
On Tue, 5 Dec 2006, Elias Torres wrote:
Also, remember, we are going after a declarative mechanism that binds
structure to presentation and we don't know ahead of time all of the
properties that are attached to a structure.
I don't see why this is a problem.
On 12/5/06, Sam Ruby [EMAIL PROTECTED] wrote:
In case there is anybody here who doesn't faithfully follow my blog
grin, I have prototyped MathML + SVG + XLINK in HTML4:
... [modify parser]...
This could be designed in such a way that
it was only enabled as an about:config option. Where I
I needed a family break. I'm back, sorry for the interruption.
-Elias
Ian Hickson wrote:
On Tue, 5 Dec 2006, Elias Torres wrote:
A few comments on your code. You can handle with n-levels deep, but
not really nested property.
Why not? I don't understand. Could you give concrete examples?
I believe the 'index' link type definition isn't quite right, considering
prior definitions of the term[1]. It seems to me that 'index' would be more
appropriate, given its prior definitions, for linking to things like CSS2.1's
list of properties (Appendix F).
Thomas Broyer wrote:
There's no need to fetch every link if you base your assumptions on
the type= attribute (and *only* the type= attribute, not the
combination with any special rel= attribute value).
How does this solution deal with, e.g. hAtom?
http://microformats.org/wiki/hatom
The
* Ian Hickson wrote:
I agree that the requirements could be deduced. But unless they are
actually there, they aren't actually there. If you see what I mean.
If something can be deduced it is there for all intents and purposes.
You can look at this from a very practical perspective: someone wants
38 matches
Mail list logo
