On 28 August 2013 14:32, Anne van Kesteren ann...@annevk.nl wrote:
We have thought of three approaches for zip URL design thus far:
* Using a sub-scheme (zip) with a zip-path (after !):
zip:http://www.example.org/zip!image.gif
* Introducing a zip-path (after %!):
Merci beaucoup Pierre. That was quite a detailed reply!
--
Nicholas.
http://www.w3.org/TR/html-markup/th.html#th.attrs.scope Says nothing
about what a UA should do by default, nor when scope can be omitted
due to such defaults.
I suggest explicitly defining defaults for the benefit of both UAs and
HTML authors. I would expect the defaults to be defined something
On 1 October 2012 10:21, Michael[tm] Smith m...@w3.org wrote:
Don't look to that document for any information about default UA behavior,
or anything at all about UA processing behavior. I tried to make that very
clear in the abstract and intro for that document.
Sorry, I never saw that:
On 30 Jul 2008, at 4:49 am, Ian Hickson wrote:
On Tue, 20 Mar 2007, Nicholas Shanks wrote:
I asked for the resurrection of HTML+'s imagefallback/image
element
last month. The reasons I cited were exactly the same as the reasons
being given now in favour of the video element, however I
that
turns off all kinds of sniffing and hacks that the browser does to
support the ‘real internet’ (so, in this case, it would display text).
This would be incredibly useful as a debugging tool when working on
large web sites that I didn't author.
— Nicholas Shanks.
smime.p7s
Description
On 14 May 2008, at 12:11 AM, Ian Hickson wrote:
On Tue, 13 May 2008, Křištof Želechovski wrote:
Removing @rev is harmful for Lynx because that is how it decides
who the
author is.
Removing rev= from the spec doesn't preclude Lynx still supporting
it
for legacy documents, and for new
as blah blah blah!
This usage has nothing to do with disambiguation, and is only
concerned with text-to-speech (even if that speech is unspoken). As
such, these kinds of abbreviations should not be marked up IMO, but
left to the synthesizer's lexicon.
On Mon, 21 Apr 2008, Nicholas Shanks wrote
make
things unnecessarily difficult for currently valid HTML4 to migrate to
valid HTML5.
— Nicholas Shanks.
smime.p7s
Description: S/MIME cryptographic signature
of the resource
(file name), the final part of the path.
I do not believe this is in scope for the specification. I don't see
an
interoperability issue here.
But it does sound like a potential security issue, re-titling external
documents.
— Nicholas Shanks.
smime.p7s
Description: S/MIME
for this lack of use which should be addressed. Are
the elements necessary in HTML, should the information they convey be
specified in another manner completely?
[1] http://code.google.com/webstats/
— Nicholas Shanks.
smime.p7s
Description: S/MIME cryptographic signature
quality.
Re-encode it into ogg from the source material, and make sure your ogg
exporter settings are apropriate for the delivery medium you want.
— Nicholas Shanks.
smime.p7s
Description: S/MIME cryptographic signature
tree and apply media-less and aural
CSS (and potentially never display anything on screen).
visibility: hidden and display: none should both hide content from
screen readers.
— Nicholas Shanks.
smime.p7s
Description: S/MIME cryptographic signature
On 1 Apr 2008, at 10:14 am, Benjamin Hawkes-Lewis wrote:
Nicholas Shanks wrote:
I know that everyone already knows this, but I think a reminder
might be timely:
Be careful not to confuse screen readers, who's job it is to read
what is displayed on the screen,
That's something
be embedded into HTML, using similar
principles as is being considered for SVG.
Lars Gunther
— Nicholas Shanks.
smime.p7s
Description: S/MIME cryptographic signature
the content but to report it to screen
readers? Or maybe a noview/ element could be used to surround
content that shouldn't be displayed but should be accessible to
screen readers?
Any thoughts?
-Nicholas
Looking for last minute shopping deals? Find them fast with Yahoo!
Search.
— Nicholas
On 9 Jan 2008, at 16:54, Simon Pieters wrote:
Siemova wrote:
The easiest, most obvious solution would be to create an attribute
for Ordered Lists -- let's call it order= -- which would have two
possible values: ftl (first to last) and ltf (last to first).
if we go this route, i'd prefer
On 27 Jun 2007, at 09:28, Maik Merten wrote:
Browsers don't rely on the OS to decode JPEG or PNG or GIF either
In my experience that seems to be exactly what they do do—rely on the
OS to provide image decoding (as with other AV media).
I say this because changes that had occurred in the OS
On 27 Jun 2007, at 11:55, Robert O'Callahan wrote:
In my experience...
You do not know what you are talking about. Firefox does not use OS
image decoders.
And I don't use Firefox, so my point is still valid. Please don't
inform me of what you think I know or do not know, it is impolite.
I don't quite get some of the arguments in the thread.
Browsers don't (and shouldn't) include their own av decoders anyway.
Codec support is an operating system issue, and any browser installed
on my computer supports exactly the same set of codecs, which are the
ones made available via the
Various people have expressed opinions in favour of either one spec
to rule them all, or two specs for different audiences. Is not the
simplest solution to have two views upon the same spec?
HTML 5, Full Version (User Agent Edition)
foo is deprecated and should not be used, but you have to
On 10 May 2007, at 07:31, Ian Hickson wrote:
On Tue, 29 Aug 2006, Anne van Kesteren wrote:
Instead of returning an uppercase six digit hex value I suggest
returning a lowercase value for compatibility with what UAs
(including
IE) currently do for CSS already and what Mozilla already does
On 10 May 2007, at 08:45, Anne van Kesteren wrote:
On Thu, 10 May 2007 09:02:52 +0200, Nicholas Shanks
[EMAIL PROTECTED] wrote:
Would it not make more sense to fix the UAs.
lower-case hex is horrible to read.
Feel free to convince the Microsoft Internet Explorer team. Then
again, it's
May I suggest that you also allow the DOM referrer attribute to
match a HTTP Referrer header if one is present, and fall back to
the Referer header otherwise. This provides for HTML 5 compliant
UAs to be forwards compatible with a potential future HTTP spec that
fixes the typo.
Also, the
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
On 7 Apr 2007, at 02:56, Anne van Kesteren wrote:
The tokenization section should also handle:
!--
!---
as correct comments for compat with the web. This means that
!
shows -- and that
!-
shows --.
Why on earth is this a good idea?
AFAIK browsers and other HTML clients
On 7 Apr 2007, at 15:47, Anne van Kesteren wrote:
On Sat, 07 Apr 2007 14:27:14 +0200, Nicholas Shanks
[EMAIL PROTECTED] wrote:
AFAIK browsers and other HTML clients don't currently treat these as
comments, [...]
Well, sorry to say, you got your facts wrong.
*sigh*
I guess that means we're
On 7 Apr 2007, at 23:48, David Håsäther wrote:
Markup starting with ! are declarations in SGML not tags.
Yeah, sorry. I added the doctype bit after object and forgot to go
back and amend the introductory statement. Consider the question to
be tags and declarations that don't start with
On 25 Mar 2007, at 23:13, Simon Pieters wrote:
The current draft of HTML5 has an automatic cross-reference feature
with the span, abbr, code, var, samp, and i elements, which would
point to a matching dfn element.
I don't see tens of thousands of web developers crying out for this
kind
On 24 Mar 2007, at 16:57, Anne van Kesteren wrote:
The dateTime DOM attribute is spelled with an uppercase T:
http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-79359609
I just encountered that while implementing longdesc support. The IMG
attribute is lower-case, the DOM attribute is
On 23 Mar 2007, at 02:27, Robert Brodrecht wrote:
Just because most ... doesn't bother doesn't mean it ought to be
removed.
So let's not ignore elements because no one uses them.
Ignore them because they are useless.
I was thinking more along the lines of:
1) We start with a set containing
On 23 Mar 2007, at 13:17, Anne van Kesteren wrote:
On Fri, 23 Mar 2007 13:40:47 +0100, Nicholas Shanks
[EMAIL PROTECTED] wrote:
Mostly unused, not even deprecated, these elements bloat the spec,
confuse lay authors (i.e. those not of a computer science background)
and I feel would be better
On 23 Mar 2007, at 17:59, Henri Sivonen wrote:
pretending that applet doesn't exist won't make applets
disappear. :-(
Perhaps not, but this will:
applet { display: none !important; }
:o)
- Nicholas.
smime.p7s
Description: S/MIME cryptographic signature
On 23 Mar 2007, at 20:47, Maciej Stachowiak wrote:
I agree the repetition of source/src is a little weird.
and name the new element something like alt
I don't like abbreviations such as alt and src.
The use case is uncommon enough that alternate wouldn't be too much
of a burden to type and
On 22 Mar 2007, at 00:08, Maciej Stachowiak proposed:
CSS Timed Media Module
HTML Timed Media Elements
• On volume:
The volume property is currently inconsistent in the string names
defined:
http://webkit.org/specs/Timed_Media_CSS.html#propdef-volume
Value: reads silent | soft | medium |
On 22 Mar 2007, at 14:16, Gervase Markham wrote:
Martin Atkins wrote:
Perhaps you and I have different ideas about what is meant by
full screen, but why would a page need to hide anything when the
video is full screen? The page itself won't be visible, because
the video will be taking up
On 22 Mar 2007, at 16:11, Robert Sayre wrote:
On 3/22/07, Gervase Markham [EMAIL PROTECTED] wrote:
Would it not have made more sense to at least have asked the WHAT-WG
No.
I think you're wrong and clearly I'm not alone. In fact I think legal
matters *should* be discussed here and
On 22 Mar 2007, at 20:53, Silvia Pfeiffer wrote:
Sorry to jump into this conversation at such a late point, but I only
just joined the mailing list.
About 8 years ago, we had the idea of using fragment offsets to start
playing from offsets of media files. However, in discussions with the
URI
Continuing today's flood of emails from me to this list, here's another.
Note: I never bothered to read this thread the first time, but since
Henri has brought to the top of my email client again, I started from
the beginning.
I want to comment on the eight bullets given at:
On 23 Mar 2007, at 01:30, Sander Tekelenburg wrote:
(Note that a mechanism to allow authors to define anchors in videos
is not a
solution, because it's then still the author who is in control.
What I'm
suggesting is about giving the user control.)
Can't we have all of:
1) A way for
On 21 Mar 2007, at 09:37, Henri Sivonen wrote:
OTOH, the left/right alignment of table cells *is* often tightly
coupled with the cell data, which suggests that the cell alignment
attributes should not be dropped.
Alternatively it could just be allowed on the col and colspan,
where it
On 21 Mar 2007, at 12:43, Sander Tekelenburg wrote:
Something else concerning first-class Netizenry: I'd like to see
the spec to
require UAs support implicit anchors, so that one can link to a
specific
startpoint: URL:http://domain.example/movie.ogg#21:08, to mean
fetch the
movie and start
On 20 Mar 2007, at 21:50, Benjamin Hawkes-Lewis wrote:
Ian Hickson wrote:
However, I think if object is so widely derided by everyone,
than I
think it needs to be depreciated sooner rather than later.
I have seriously considered doing this. Unfortunately I don't
think we can
actually
On 17 Mar 2007, at 23:28, Andrew Fedoniouk wrote:
I think that in most cases will be better if we could package
complex pages into zip envelopes and deliver them in the whole.
That would be real solution of jumps. And img width=...
height=...
is a palliative.
I have an open bug with
On 21 Mar 2007, at 00:27, Simon Pieters wrote:
I asked for the resurrection of HTML+'s imagefallback/image
element last month. I was told that would break existing
implementations
Existing implementations include at least:
* Internet Explorer
* Firefox
* Opera
* Safari
The image start
Given XHTML 2.0's idea of an element for navigation list (using nl
as the tag [1]), it occurred to me that menu, deprecated in HTML 4
but resurrected in HTML 5, would be entirely suitable for this
purpose and fully backwards compatible. From what I can gather, this
was the intended purpose
Discussion on aspect ratio:
You may want to consider aspect ratio too: ratio=preserve being
default, ratio=1.333 could indicate 4:3 or get tricky and accept
16:9 for precision reasons.
Wouldn't we simply always want to use the authored size?
Do videos encode what size they are best
On 16 Mar 2007, at 15:32, Shadow2531 wrote:
.loop, .startpos
loop = false | true
autostart = true | false
startpos = 0 | specified pos
Could you elaborate on the use cases for these?
video src=VideoIWasWatching.ogg
param name=startpos value=value gotten from cookie where I
left off at
On 12 Mar 2007, at 20:19, Andrew Fedoniouk wrote:
Case:
td a href=1.htmxyz/a/td
td a href=2.htmxyz-xyz-xyz/a/td
is perfectly valid from some abstract semantic machine
point of view but for human these two cells are not
equal. At least hit area is different. And visual perception too.
All you
On 2 Mar 2007, at 10:01, Gervase Markham wrote:
I think a base format is vital. With img we had de-facto standard
formats because of what the first browsers supported. It took ages
to get another one added (PNG) and it wasn't widely used until
browser support firmed up.
If a base format
On 2 Mar 2007, at 17:00, Alexey Feldgendler wrote:
Likewise, HTML has a to explicitly express the semantics of a
hyperlink. I don't see how the language would benefit from the
ability of turning any element into a link.
The main use I would put it to is on li elements, especially tables
On 1 Mar 2007, at 11:56, Anne van Kesteren wrote:
That's one of the reasons a dedicated element is better than
reusing the object element. All the new video specific APIs would
otherwise have to be defined for all possible things the object
element can represent (images, nested browser
On 9 Feb 2007, at 07:47, Karl Dubost wrote:
Le 8 févr. 2007 à 20:17, Nicholas Shanks a écrit :
On 6 Feb 2007, at 07:57, Karl Dubost wrote:
http://www.w3.org/MarkUp/HTMLPlus/htmlplus_1.html
I wish the imagefallback/image tags had made it through the
years. It's so much better than img alt
On 9 Feb 2007, at 15:51, Benjamin Hawkes-Lewis wrote:
Nicholas Shanks wrote:
Yes, like OBJECT, but with a different name. A nicer name than
IMG. One
with three vowels. One that only accepts image/* content types. One
with a more specific usage that can be controlled independently of
OBJECT
On 9 Feb 2007, at 17:19, David Latapie wrote:
- small: It does not cope well inline. I (almost) never use small in a
paragraph; I use it for one-liners, e.g. smallsource:/small or
smallNo this is a long post, right?/small
Agreed, when I use small, which these days is just for things like
On 8 Feb 2007, at 15:23, Leons Petrazickis wrote:
In the Western world, the standard for highlighting is a neon yellow
background. I submit that a much better name for m is hi
(hilite, highlite, highlight).
I don't like the look of hi — it doesn't tell me what it does
very well. Maybe it
On 8 Feb 2007, at 18:00, David Latapie wrote:
Problem with mark/m is that its meaning is confusing.
I don't think it's any more confusing than hi would be. See below...
And still don't see any difference with em or strong. How would
you
pronounce an important word? How would you pronounce
On 6 Feb 2007, at 07:57, Karl Dubost wrote:
unlikely. div and span elements didn't exist in HTML+.
http://www.w3.org/MarkUp/HTMLPlus/htmlplus_1.html
Ironically I was just reading that earlier today, then saw your post!
(I hadn't been reading this thread.)
I wish the imagefallback/image
On 8 Feb 2007, at 22:31, Henri Sivonen wrote:
On Feb 8, 2007, at 21:09, Nicholas Shanks wrote:
de-em, de-emph, subdue or other new element
What would the default visual presentation be?
One or more of:
none (i.e. same as span: 'inherit everything')
opacity: 0.8
font-size: smaller
On concern that we would be 'wasting' such a short element name for
such an esoteric usage, why not call it mark instead?
- Nicholas.
smime.p7s
Description: S/MIME cryptographic signature
Having come in to this conversation half way, I'd like to give my
opinions. In the following 'default style' means in the UAs style
declarations for all documents of the language.
There should be three emphasis elements:
em Increases emphatic semantics by one level. *No* default
On 5 Sep 2006, at 12:54, Charles McCathieNevile wrote:
Instead of returning an uppercase six digit hex value I suggest
returning a lowercase value for compatibility with what UAs
(including IE) currently do
It may be the right decision on compatibility grounds, but other
than that
a user agent would likely find it
falls back to them much more often than for 'serif' and 'sans-serif'.
- Nicholas Shanks.
smime.p7s
Description: S/MIME cryptographic signature
Hi Håkon, thanks for replying.
Why not just follow the guidelines in the CSS3 font module?:
Ahh, I didn't see there were instructions on the module itself on
where to send suggestions, and it doesn't give the main author's name
(just the CSS2 authors and Tantek… et al).
I was on that css
64 matches
Mail list logo
