Ineiev writes:
> Still it's an issue.
OK, have it your way. I suspect that you will not decrease the number
of complaints by much, but *shrug* it won't be my problem.
Ineiev writes:
> GNU webmasters did receive reports from such visitors. I'm sure many
> cases were not reported.
If GNU websites are correctly configured and send the correct MIME
charset in the Content-Type in the HTTP headers, the users should not
have a problem, and if they do have such prob
Ineiev writes:
> On Wed, Dec 24, 2014 at 12:27:25PM +0900, Stephen J. Turnbull wrote:
> > AFAIK the encoding declaration is optional, defaulting to UTF-8. In
> > that case, we can (and IMHO *should*, but I am no longer an expert on
> > current encoding practice) require that our software gener
On Fri, Dec 26, 2014 at 02:09:33AM +0900, Stephen J. Turnbull wrote:
> Ineiev writes:
>
> > GNU webmasters did receive reports from such visitors. I'm sure many
> > cases were not reported.
>
> If GNU websites are correctly configured and send the correct MIME
> charset in the Content-Type in t
On Fri, Dec 26, 2014 at 12:58:24AM +0900, Stephen J. Turnbull wrote:
> Ineiev writes:
> > On Wed, Dec 24, 2014 at 12:27:25PM +0900, Stephen J. Turnbull wrote:
> > > AFAIK the encoding declaration is optional, defaulting to UTF-8. In
> > > that case, we can (and IMHO *should*, but I am no longer
On Wed, Dec 24, 2014 at 12:27:25PM +0900, Stephen J. Turnbull wrote:
> AFAIK the encoding declaration is optional, defaulting to UTF-8. In
> that case, we can (and IMHO *should*, but I am no longer an expert on
> current encoding practice) require that our software generate UTF-8
> and omit the de
Hello,
On Wed, Dec 24, 2014 at 12:59:32AM +0700, Yuri Khan wrote:
>
> What browsers are there that do not support CSS *and* at the same time
> have the capability of displaying proportional fonts?
They may not be able to exactly display proportional fonts, but they
may highlight it in a differen
We could use Image::Size.
http://search.cpan.org/~rjray/Image-Size-3.232/
Looks good. Evidently it natively understands all the common formats.
K
Yuri Khan writes:
> As of this past October, that transition period is over.
Just plain wrong. The transition period *never* ends, as long as
there are any documents specifying older standards, or browsers
supporting them. Transitional standards are a compatibility tool, not
a mandate. And th
On Tue, Dec 23, 2014 at 05:04:38PM -0700, Karl Berry wrote:
> and if it was possible why would it the role of makeinfo to
> do that?
>
> It is useful to put the actual width/height of images in the HTML output
> because then browsers can use that info for layout without having to
> read th
and if it was possible why would it the role of makeinfo to
do that?
It is useful to put the actual width/height of images in the HTML output
because then browsers can use that info for layout without having to
read the actual image. On files with lots of images, it can make a
noticeable
On Tue, Dec 23, 2014 at 10:57:15PM +0100, Lennart Borgman wrote:
>
> Is there a chance that you can add html attributes for height and
> width on -tags? I mean as read from the actual images.
I don't get it. Why would we do that, and how? I do not know how to
read the height and width from the
On Tue, Dec 23, 2014 at 5:55 PM, Patrice Dumas wrote:
> On Tue, Dec 23, 2014 at 11:44:24AM +0100, Lennart Borgman wrote:
>> On Tue, Dec 23, 2014 at 11:37 AM, Ivan Shmakov wrote:
>>
>> >
>> > I hereby suggest that:
>> >
>> > • is replaced with
>> > ;
>> >
>>
>>
>> No. ;-
> The problem is that for a couple of months now, the most recent
> HTML version is HTML5, and it does /not/ specify these elements.
>
> Granted, there’re browsers which still support these, but I
> could easily imagine a new browser project being started that
>
On Tue, Dec 23, 2014 at 06:14:01PM +, Gavin Smith wrote:
> On Tue, Dec 23, 2014 at 4:49 PM, Patrice Dumas wrote:
> > First of all it is a bit unclear where this html comes from. In
> > general, both texi2html and texi2any/makeinfo, especially for makeinfo
> > starting at version 5 render prop
On Tue, Dec 23, 2014 at 4:49 PM, Patrice Dumas wrote:
> First of all it is a bit unclear where this html comes from. In
> general, both texi2html and texi2any/makeinfo, especially for makeinfo
> starting at version 5 render properly nested html tags.
>
Could it be coming from some HTML output cus
On Tue, Dec 23, 2014 at 10:49 PM, Patrice Dumas wrote:
> First of all it is a bit unclear where this html comes from. In
> general, both texi2html and texi2any/makeinfo, especially for makeinfo
> starting at version 5 render properly nested html tags.
I haven’t checked. David Kastrup posted it
Patrice Dumas writes:
> Hello,
>
> First of all it is a bit unclear where this html comes from. In
> general, both texi2html and texi2any/makeinfo, especially for makeinfo
> starting at version 5 render properly nested html tags.
Ok, I've just pulled this example from the current LilyPond web
> Patrice Dumas writes:
> On Tue, Dec 23, 2014 at 09:29:07PM +0700, Yuri Khan wrote:
>>> • the element is /always/ used instead of ;
>> Cursory reading of HTML.pm seems to indicate that is
>> currently*** used for @key, @t, @verb, and some kinds of tables
>> possibly related to @ex
On Tue, Dec 23, 2014 at 11:44:24AM +0100, Lennart Borgman wrote:
> On Tue, Dec 23, 2014 at 11:37 AM, Ivan Shmakov wrote:
>
> >
> > I hereby suggest that:
> >
> > • is replaced with
> > ;
> >
>
>
> No. ;-) Please never use inline styles. Use a class name instead (+ CSS
Hello,
First of all it is a bit unclear where this html comes from. In
general, both texi2html and texi2any/makeinfo, especially for makeinfo
starting at version 5 render properly nested html tags.
On Tue, Dec 23, 2014 at 09:29:07PM +0700, Yuri Khan wrote:
> >
> > • the element is /al
On Tue, Dec 23, 2014 at 9:37 PM, Ivan Shmakov wrote:
> In this snippet, I count 2 instances of improper tag nesting,
>
> >> I count just a single one, but yes, that second surely
> >> invalidates the fragment.
>
> > is improper* nesting in my book. All paired tags SHOULD**
> > be exp
> Yuri Khan writes:
> On Tue, Dec 23, 2014 at 4:37 PM, Ivan Shmakov wrote:
In this snippet, I count 2 instances of improper tag nesting,
>> I count just a single one, but yes, that second surely
>> invalidates the fragment.
> is improper* nesting in my book. All paired tags
On Tue, Dec 23, 2014 at 4:37 PM, Ivan Shmakov wrote:
> >>> href="79/lily-83620d4b.ly">‘accidental-ancient.ly’
> >>>
> >>>
> >>> >>>border="0"
> >>>src="79/lily-83620d4b.png"
> >>>alt="[image of music]">
> >>>
> >>>
>
> >> In this snippet, I count 2 i
On Tue, Dec 23, 2014 at 3:29 PM, Yuri Khan wrote:
> On Tue, Dec 23, 2014 at 4:37 PM, Ivan Shmakov wrote:
>> >>> > href="79/lily-83620d4b.ly">‘accidental-ancient.ly’
>> >>>
>> >>>
>> >>> > >>>border="0"
>> >>>src="79/lily-83620d4b.png"
>> >>>alt="[image of m
> David Kastrup writes:
> Yuri Khan writes:
> On Sun, Dec 21, 2014 at 11:57 PM, David Kastrup wrote:
>>> Well, the HTML looks like
>>> >> href="79/lily-83620d4b.ly">‘accidental-ancient.ly’
>>>
>>>
>>> >>border="0"
>>>src="79/lily-83620d4b.png"
>>>
On Tue, Dec 23, 2014 at 11:37 AM, Ivan Shmakov wrote:
>
> I hereby suggest that:
>
> • is replaced with
> ;
>
No. ;-) Please never use inline styles. Use a class name instead (+ CSS
code for that class).
27 matches
Mail list logo
