Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #40104 > unrolled thread

Re: ANN: Dogelog: We Have Liftoff, We Have Liftoff

Back to article view | Back to comp.lang.javascript

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: ANN: Dogelog: We Have Liftoff, We Have Liftoff "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2021-05-24 19:25 -0700
    Re: ANN: Dogelog: We Have Liftoff, We Have Liftoff Mostowski Collapse <janburse@fastmail.fm> - 2021-05-25 09:34 +0200
      Re: ANN: Dogelog: We Have Liftoff, We Have Liftoff "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2021-05-25 06:11 -0700
        Re: ANN: Dogelog: We Have Liftoff, We Have Liftoff Mostowski Collapse <janburse@fastmail.fm> - 2021-05-25 18:35 +0200
          Re: ANN: Dogelog: We Have Liftoff, We Have Liftoff "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2021-05-25 11:06 -0700
            Re: ANN: Dogelog: We Have Liftoff, We Have Liftoff Mostowski Collapse <janburse@fastmail.fm> - 2021-05-25 20:28 +0200
              Re: ANN: Dogelog: We Have Liftoff, We Have Liftoff Mostowski Collapse <janburse@fastmail.fm> - 2021-05-25 20:30 +0200
                Re: ANN: Dogelog: We Have Liftoff, We Have Liftoff "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2021-05-25 11:39 -0700
                Re: ANN: Dogelog: We Have Liftoff, We Have Liftoff "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2021-05-25 11:38 -0700
                  Re: ANN: Dogelog: We Have Liftoff, We Have Liftoff Mostowski Collapse <janburse@fastmail.fm> - 2021-05-25 20:47 +0200
                    Re: ANN: Dogelog: We Have Liftoff, We Have Liftoff Mostowski Collapse <janburse@fastmail.fm> - 2021-05-25 20:54 +0200
                      Re: ANN: Dogelog: We Have Liftoff, We Have Liftoff Mostowski Collapse <janburse@fastmail.fm> - 2021-05-25 20:59 +0200
                        Re: ANN: Dogelog: We Have Liftoff, We Have Liftoff Mostowski Collapse <janburse@fastmail.fm> - 2021-05-25 21:03 +0200
                        Re: ANN: Dogelog: We Have Liftoff, We Have Liftoff Jon Ribbens <jon+usenet@unequivocal.eu> - 2021-05-25 19:42 +0000
                          Re: ANN: Dogelog: We Have Liftoff, We Have Liftoff Mostowski Collapse <janburse@fastmail.fm> - 2021-05-25 22:05 +0200
                            Re: ANN: Dogelog: We Have Liftoff, We Have Liftoff Mostowski Collapse <janburse@fastmail.fm> - 2021-05-25 22:27 +0200
                          Re: ANN: Dogelog: We Have Liftoff, We Have Liftoff Mostowski Collapse <janburse@fastmail.fm> - 2021-05-25 22:01 +0200
                          Re: ANN: Dogelog: We Have Liftoff, We Have Liftoff Arno Welzel <usenet@arnowelzel.de> - 2021-06-13 17:53 +0200
                    Re: ANN: Dogelog: We Have Liftoff, We Have Liftoff "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2021-05-25 11:51 -0700
                Re: ANN: Dogelog: We Have Liftoff, We Have Liftoff Mostowski Collapse <janburse@fastmail.fm> - 2021-05-25 20:34 +0200
                  Re: ANN: Dogelog: We Have Liftoff, We Have Liftoff "Mark-" <nospam@mapson.xyz> - 2021-05-26 01:11 +0000
                    Re: ANN: Dogelog: We Have Liftoff, We Have Liftoff Mostowski Collapse <janburse@fastmail.fm> - 2021-05-26 08:33 +0200
                      Re: ANN: Dogelog: We Have Liftoff, We Have Liftoff Mostowski Collapse <janburse@fastmail.fm> - 2021-05-26 08:37 +0200
                        Re: ANN: Dogelog: We Have Liftoff, We Have Liftoff Arno Welzel <usenet@arnowelzel.de> - 2021-06-13 18:06 +0200
                      Re: ANN: Dogelog: We Have Liftoff, We Have Liftoff "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2021-05-26 06:14 -0700
                        Re: ANN: Dogelog: We Have Liftoff, We Have Liftoff Jon Ribbens <jon+usenet@unequivocal.eu> - 2021-05-26 13:21 +0000
                          Re: ANN: Dogelog: We Have Liftoff, We Have Liftoff "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2021-05-26 06:38 -0700
                            Re: ANN: Dogelog: We Have Liftoff, We Have Liftoff Jon Ribbens <jon+usenet@unequivocal.eu> - 2021-05-26 13:56 +0000
                              Re: ANN: Dogelog: We Have Liftoff, We Have Liftoff "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2021-05-26 07:08 -0700
                                Re: ANN: Dogelog: We Have Liftoff, We Have Liftoff Jon Ribbens <jon+usenet@unequivocal.eu> - 2021-05-26 14:15 +0000
                                  Re: ANN: Dogelog: We Have Liftoff, We Have Liftoff "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2021-05-26 07:34 -0700
                                    Re: ANN: Dogelog: We Have Liftoff, We Have Liftoff Jon Ribbens <jon+usenet@unequivocal.eu> - 2021-05-26 16:00 +0000
                                      Re: ANN: Dogelog: We Have Liftoff, We Have Liftoff "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2021-05-26 09:50 -0700
                                        Re: ANN: Dogelog: We Have Liftoff, We Have Liftoff Jon Ribbens <jon+usenet@unequivocal.eu> - 2021-05-26 19:12 +0000
                                    Re: ANN: Dogelog: We Have Liftoff, We Have Liftoff Arno Welzel <usenet@arnowelzel.de> - 2021-06-13 18:31 +0200
                                Re: ANN: Dogelog: We Have Liftoff, We Have Liftoff Arno Welzel <usenet@arnowelzel.de> - 2021-06-13 18:25 +0200
                            Re: ANN: Dogelog: We Have Liftoff, We Have Liftoff Arno Welzel <usenet@arnowelzel.de> - 2021-06-13 18:18 +0200
                    Re: ANN: Dogelog: We Have Liftoff, We Have Liftoff Mostowski Collapse <janburse@fastmail.fm> - 2021-05-26 08:29 +0200
                      Re: ANN: Dogelog: We Have Liftoff, We Have Liftoff Arno Welzel <usenet@arnowelzel.de> - 2021-06-13 17:55 +0200
                        Re: ANN: Dogelog: We Have Liftoff, We Have Liftoff "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2021-06-13 10:03 -0700
                        Re: ANN: Dogelog: We Have Liftoff, We Have Liftoff Mostowski Collapse <bursejan@gmail.com> - 2021-06-13 10:07 -0700
                          Re: ANN: Dogelog: We Have Liftoff, We Have Liftoff Mostowski Collapse <bursejan@gmail.com> - 2021-06-13 10:12 -0700
                            Re: ANN: Dogelog: We Have Liftoff, We Have Liftoff Mostowski Collapse <bursejan@gmail.com> - 2021-06-13 10:18 -0700
                              Re: ANN: Dogelog: We Have Liftoff, We Have Liftoff Mostowski Collapse <bursejan@gmail.com> - 2021-06-30 11:18 -0700
              Re: ANN: Dogelog: We Have Liftoff, We Have Liftoff "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2021-05-25 11:42 -0700

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#40144

Mostowski Collapse wrote:

> And maybe update your shitty website:
> https://thenewobjective.com/about
> 
> I have never seen a more sadenning thing.
> Also the font size is way too large, cant
> read anything without getting headache.

Nothing wrong with his website. You don't like it, so what.

[toc] | [prev] | [next] | [standalone]

#40150

Hint, if you want to make websites that work
on mobile and desktop, there are other
approaches than just having elephant font size.

Mostowski Collapse schrieb:
> Nothing wrong with the name Dogelog,
> Jon Ribbens doesn't like it, so what.
> 
> Mark- schrieb:
>> Mostowski Collapse wrote:
>>
>>> And maybe update your shitty website:
>>> https://thenewobjective.com/about
>>>
>>> I have never seen a more sadenning thing.
>>> Also the font size is way too large, cant
>>> read anything without getting headache.
>>
>> Nothing wrong with his website. You don't like it, so what.
>>
> 

[toc] | [prev] | [next] | [standalone]

#40152

Same holds for this website:
https://www.defprogramming.com/authors/

Its rather a horrible website, can read anything
unless you have your browser page occupying the
whole screen. It does some rescaling

but I guess it needs some fine tuning. At
least on an MacBook Air 2019 with Safari
browser its not usable.

Mostowski Collapse schrieb:
> 
> Hint, if you want to make websites that work
> on mobile and desktop, there are other
> approaches than just having elephant font size.
> 
> Mostowski Collapse schrieb:
>> Nothing wrong with the name Dogelog,
>> Jon Ribbens doesn't like it, so what.
>>
>> Mark- schrieb:
>>> Mostowski Collapse wrote:
>>>
>>>> And maybe update your shitty website:
>>>> https://thenewobjective.com/about
>>>>
>>>> I have never seen a more sadenning thing.
>>>> Also the font size is way too large, cant
>>>> read anything without getting headache.
>>>
>>> Nothing wrong with his website. You don't like it, so what.
>>>
>>
> 

[toc] | [prev] | [next] | [standalone]

#40210

Mostowski Collapse:

> Same holds for this website:
> https://www.defprogramming.com/authors/
> 
> Its rather a horrible website, can read anything
> unless you have your browser page occupying the
> whole screen. It does some rescaling

Works for me without issue - browser not in full screen. Screenshots:

<https://nextcloud.0x0c.de/s/wd5ms9Lip8SAZTB/preview>
<https://nextcloud.0x0c.de/s/j8FL8GYWj55Ep3k/preview>

For mobile devices the font could be a bit smaller in the author list,
but it generally works and is usable:

<https://nextcloud.0x0c.de/s/NS3AwGaBF8p69Z3/preview>
<https://nextcloud.0x0c.de/s/pbaWFB2JJMb4rMD/preview>

> but I guess it needs some fine tuning. At
> least on an MacBook Air 2019 with Safari
> browser its not usable.

Screenshots? The above screenshots are taken with Windows 10 Pro using
Vivaldi on a 4K display and a Xiaomi Mi 9 Lite with Samsung Internet
browser (which is Chromium based).


-- 
Arno Welzel
https://arnowelzel.de

[toc] | [prev] | [next] | [standalone]

#40154

On Wednesday, May 26, 2021 at 1:33:27 AM UTC-5, Mostowski Collapse wrote:
> Hint, if you want to make websites that work 
> on mobile and desktop, there are other 
> approaches than just having elephant font size. 

The font size is relative to the viewport size. I think the problem is between your keyboard and chair. 

Sitting 6 inches from the screen is not healthy for you.

[toc] | [prev] | [next] | [standalone]

#40155

On 2021-05-26, Michael Haufe (TNO) <tno@thenewobjective.com> wrote:
> On Wednesday, May 26, 2021 at 1:33:27 AM UTC-5, Mostowski Collapse wrote:
>> Hint, if you want to make websites that work 
>> on mobile and desktop, there are other 
>> approaches than just having elephant font size. 
>
> The font size is relative to the viewport size.

That's a pretty weird thing to do, to be fair.

[toc] | [prev] | [next] | [standalone]

#40156

On Wednesday, May 26, 2021 at 8:21:10 AM UTC-5, Jon Ribbens wrote:
> On 2021-05-26, Michael Haufe (TNO) <t...@thenewobjective.com> wrote: 
> > On Wednesday, May 26, 2021 at 1:33:27 AM UTC-5, Mostowski Collapse wrote: 
> >> Hint, if you want to make websites that work 
> >> on mobile and desktop, there are other 
> >> approaches than just having elephant font size. 
> > 
> > The font size is relative to the viewport size.
> That's a pretty weird thing to do, to be fair.

Uncommon yes, but not that weird:

<https://www.smashingmagazine.com/2016/05/fluid-typography/>
<https://web.archive.org/web/20200926083516/https://www.csshero.org/css-viewport-units-css-hero/>
<https://css-tricks.com/viewport-sized-typography/>

[toc] | [prev] | [next] | [standalone]

#40157

On 2021-05-26, Michael Haufe (TNO) <tno@thenewobjective.com> wrote:
> On Wednesday, May 26, 2021 at 8:21:10 AM UTC-5, Jon Ribbens wrote:
>> On 2021-05-26, Michael Haufe (TNO) <t...@thenewobjective.com> wrote: 
>> > The font size is relative to the viewport size.
>> That's a pretty weird thing to do, to be fair.
>
> Uncommon yes, but not that weird:
>
><https://www.smashingmagazine.com/2016/05/fluid-typography/>
><https://web.archive.org/web/20200926083516/https://www.csshero.org/css-viewport-units-css-hero/>
><https://css-tricks.com/viewport-sized-typography/>

Those articles seem deeply confused, especially the first, which says:

    This might be because typography is so deeply rooted in the
    centuries-old history of typesetting. The concept of having “fluid”
    anything is often at odds with this tradition. In print, dimensions
    have always been fixed, but they don’t need to be on the web. That’s
    why I think fluid typography is a perfect match for the web. It’s a
    different approach for a completely different medium.

Using 'viewport width' for the font size *isn't* fluid, it's the
exact opposite. It's paper-based thinking in a paperless world.
It means the content doesn't format itself appropriately for the
page, it just shrinks and expands like a photocopier on 'enlarge'
mode.

(The 'guess what the icon means' navigation is also a bad idea
by the way ;-) )

[toc] | [prev] | [next] | [standalone]

#40158

On Wednesday, May 26, 2021 at 8:56:59 AM UTC-5, Jon Ribbens wrote:
> [...]
> Those articles seem deeply confused, especially the first, which says: 
> 
> This might be because typography is so deeply rooted in the 
> centuries-old history of typesetting. The concept of having “fluid” 
> anything is often at odds with this tradition. In print, dimensions 
> have always been fixed, but they don’t need to be on the web. That’s 
> why I think fluid typography is a perfect match for the web. It’s a 
> different approach for a completely different medium. 
> 
> Using 'viewport width' for the font size *isn't* fluid, it's the 
> exact opposite. It's paper-based thinking in a paperless world. 
> It means the content doesn't format itself appropriately for the 
> page, it just shrinks and expands like a photocopier on 'enlarge' 
> mode. 

Given that the common practice is to use breakpoints, are those not the web equivalent of paper based thinking? 
Also recall that it's called a web "page" and and an html "document". You "scroll" the page with a "scroll"-bar. 

By definition if the font size is based on the container size (whatever that is) then that is fluid/liquid.

<https://web.archive.org/web/20190424092922/http://www.liquidapsive.com/>

> (The 'guess what the icon means' navigation is also a bad idea 
> by the way ;-) )

I don't know what you're referring to.

[toc] | [prev] | [next] | [standalone]

#40159

On 2021-05-26, Michael Haufe (TNO) <tno@thenewobjective.com> wrote:
> On Wednesday, May 26, 2021 at 8:56:59 AM UTC-5, Jon Ribbens wrote:
>> [...]
>> Those articles seem deeply confused, especially the first, which says: 
>> 
>> This might be because typography is so deeply rooted in the 
>> centuries-old history of typesetting. The concept of having “fluid” 
>> anything is often at odds with this tradition. In print, dimensions 
>> have always been fixed, but they don’t need to be on the web. That’s 
>> why I think fluid typography is a perfect match for the web. It’s a 
>> different approach for a completely different medium. 
>> 
>> Using 'viewport width' for the font size *isn't* fluid, it's the 
>> exact opposite. It's paper-based thinking in a paperless world. 
>> It means the content doesn't format itself appropriately for the 
>> page, it just shrinks and expands like a photocopier on 'enlarge' 
>> mode. 
>
> Given that the common practice is to use breakpoints, are those not
> the web equivalent of paper based thinking? 

Why would they be?

> Also recall that it's called a web "page" and and an html "document".
> You "scroll" the page with a "scroll"-bar. 

I'm not sure what your point is here.

> By definition if the font size is based on the container size
> (whatever that is) then that is fluid/liquid.

No, it's the opposite of fluid/liquid. For example, if you set the
font size to "1vw", then the text never reformats at all, it is
not fluid or liquid, it is frozen solid. Fluid/liquid is if the
font size *doesn't* change when the container size changes, and
instead the text is reformmated ("flows") appropriately for the
space available.

><https://web.archive.org/web/20190424092922/http://www.liquidapsive.com/>
>
>> (The 'guess what the icon means' navigation is also a bad idea 
>> by the way ;-) )
>
> I don't know what you're referring to.

The mystery icons down the left hand side which serve as navigation.

[toc] | [prev] | [next] | [standalone]

#40160

On Wednesday, May 26, 2021 at 9:15:12 AM UTC-5, Jon Ribbens wrote:
> On 2021-05-26, Michael Haufe (TNO) <t...@thenewobjective.com> wrote:
> > On Wednesday, May 26, 2021 at 8:56:59 AM UTC-5, Jon Ribbens wrote: 
> > [...]
> >> Using 'viewport width' for the font size *isn't* fluid, it's the 
> >> exact opposite. It's paper-based thinking in a paperless world. 
> >> It means the content doesn't format itself appropriately for the 
> >> page, it just shrinks and expands like a photocopier on 'enlarge' 
> >> mode. 
> > 
> > Given that the common practice is to use breakpoints, are those not 
> > the web equivalent of paper based thinking?
> Why would they be?

Paper has predefined standard sizes, as do viewports. Web developers 
generally use media queries to target those sizes and act accordingly. 

Given that their are dozens of these if not more, it seems a fool's errand.

> > Also recall that it's called a web "page" and and an html "document". 
> > You "scroll" the page with a "scroll"-bar.
> I'm not sure what your point is here.

Paper based thinking. We obviously have it as an industry just based on
the terminology alone.

> > By definition if the font size is based on the container size 
> > (whatever that is) then that is fluid/liquid.
> No, it's the opposite of fluid/liquid. For example, if you set the 
> font size to "1vw", then the text never reformats at all, it is 
> not fluid or liquid, it is frozen solid. Fluid/liquid is if the 
> font size *doesn't* change when the container size changes, and 
> instead the text is reformmated ("flows") appropriately for the 
> space available.

Liquids/fluids fill their container hence the name. 
You can see this definition consistently used by Adobe and others:

<https://designinginterfaces.com/patterns/liquid-layout/>
<https://helpx.adobe.com/indesign/using/alternate-layouts-liquid-layouts.html>
<http://maxdesign.com.au/articles/liquid/>
<https://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-TECHS-20071102/G146.html>
<https://www.smashingmagazine.com/2009/06/fixed-vs-fluid-vs-elastic-layout-whats-the-right-one-for-you/>

'vw' is a relative measurement, so yes it will change. 

> > I don't know what you're referring to.
> The mystery icons down the left hand side which serve as navigation.

Ah yes, for some screen sizes or orientations it does only show the icons.
I'll consider updating it to use the mobile view for those sizes.
I do appreciate the usability feedback.

[toc] | [prev] | [next] | [standalone]

#40161

On 2021-05-26, Michael Haufe (TNO) <tno@thenewobjective.com> wrote:
> On Wednesday, May 26, 2021 at 9:15:12 AM UTC-5, Jon Ribbens wrote:
>> On 2021-05-26, Michael Haufe (TNO) <t...@thenewobjective.com> wrote:
>> > Given that the common practice is to use breakpoints, are those not 
>> > the web equivalent of paper based thinking?
>> Why would they be?
>
> Paper has predefined standard sizes, as do viewports. Web developers 
> generally use media queries to target those sizes and act accordingly. 

That's not right. Viewports don't come in standard sizes. But some
frameworks have specific cut-off points at which you can make things
switch layouts because changing the layout for smaller screens is
often a good idea and testing your site on every width between 100px
and 4,000 px is impractical ;-)

>> > Also recall that it's called a web "page" and and an html "document". 
>> > You "scroll" the page with a "scroll"-bar.
>> I'm not sure what your point is here.
>
> Paper based thinking. We obviously have it as an industry just based on
> the terminology alone.

"Page", yes... "document", no. "scroll" I hadn't really thought about
before but I guess you're right, albeit that terminology pre-dates the
web by a long way of course so isn't really relevant.

>> > By definition if the font size is based on the container size 
>> > (whatever that is) then that is fluid/liquid.
>> No, it's the opposite of fluid/liquid. For example, if you set the 
>> font size to "1vw", then the text never reformats at all, it is 
>> not fluid or liquid, it is frozen solid. Fluid/liquid is if the 
>> font size *doesn't* change when the container size changes, and 
>> instead the text is reformmated ("flows") appropriately for the 
>> space available.
>
> Liquids/fluids fill their container hence the name. 

I don't think that's what the name means. It means the layout can
change shape, like a liquid can change shape. There's no implication
that the layout always fills 100% of the container like a liquid does.

> You can see this definition consistently used by Adobe and others:

Yes, I'm not arguing with the terminology, I'm saying that a font
size that varies with the container size is not an example of what
is described by that terminology - but rather the opposite.

> 'vw' is a relative measurement, so yes it will change. 

That's *why* the text layout won't change. Try it.

>> > I don't know what you're referring to.
>> The mystery icons down the left hand side which serve as navigation.
>
> Ah yes, for some screen sizes or orientations it does only show the icons.
> I'll consider updating it to use the mobile view for those sizes.
> I do appreciate the usability feedback.

It's mostly that the viewport has to be very wide indeed before the icon
labels appear.

[toc] | [prev] | [next] | [standalone]

#40162

On Wednesday, May 26, 2021 at 11:00:24 AM UTC-5, Jon Ribbens wrote:
> On 2021-05-26, Michael Haufe (TNO) <t...@thenewobjective.com> wrote: 

> > Paper has predefined standard sizes, as do viewports. Web developers 
> > generally use media queries to target those sizes and act accordingly.
> That's not right. Viewports don't come in standard sizes. But some 
> frameworks have specific cut-off points at which you can make things 
> switch layouts because changing the layout for smaller screens is 
> often a good idea and testing your site on every width between 100px 
> and 4,000 px is impractical ;-)

Screen resolutions definitely do have standard sizes. That's what
VGA, SGA, XGA, HD, 4K UHD, and others are:

<https://en.wikipedia.org/wiki/Computer_display_standard>

Admittedly I'm conflating viewport size with display resolution and the
DPI settings can make these not match but it's a common practice
to add the following to your webpages:

<meta name="viewport" content="width=device-width, initial-scale=1">

Making my conflation not too wrong. Regardless, the point is that 
a common list (def-facto or de-jure) informed by these resolution sizes
are used to define the media query breakpoints.

> > Paper based thinking. We obviously have it as an industry just based on 
> > the terminology alone.
> "Page", yes... "document", no. "scroll" I hadn't really thought about 
> before but I guess you're right, albeit that terminology pre-dates the 
> web by a long way of course so isn't really relevant.

Many words are pregnant with meaning and moving them to
a new medium also brings the baggage and mindset with it.

> >> > By definition if the font size is based on the container size 
> >> > (whatever that is) then that is fluid/liquid. 
> >> No, it's the opposite of fluid/liquid. For example, if you set the 
> >> font size to "1vw", then the text never reformats at all, it is 
> >> not fluid or liquid, it is frozen solid. Fluid/liquid is if the 
> >> font size *doesn't* change when the container size changes, and 
> >> instead the text is reformmated ("flows") appropriately for the 
> >> space available. 
> > 
> > Liquids/fluids fill their container hence the name.
> I don't think that's what the name means. It means the layout can 
> change shape, like a liquid can change shape. There's no implication 
> that the layout always fills 100% of the container like a liquid does.

Given that layouts are and have been primarily boxes I don't think
changing shape is relevant here for the definition unless you are
referring to multiple independent boxes moving their positions
dynamically.

Since we disagree on the definition, do you have a reference for your usage?

> > You can see this definition consistently used by Adobe and others:
> Yes, I'm not arguing with the terminology, I'm saying that a font 
> size that varies with the container size is not an example of what 
> is described by that terminology - but rather the opposite.

I wouldn't say the opposite as it is still dynamic but I am willing
to concede that it might be inappropriate to use a layout associated
term with text behavior.

> > 'vw' is a relative measurement, so yes it will change.
> That's *why* the text layout won't change. Try it.

It resizes based on the viewport size. Just resize the webpage to see the behavior.
What does "text layout" have to do with it? Are you referring to wrapping behavior?

> > Ah yes, for some screen sizes or orientations it does only show the icons. 
> > I'll consider updating it to use the mobile view for those sizes. 
> > I do appreciate the usability feedback.
> It's mostly that the viewport has to be very wide indeed before the icon 
> labels appear.

No longer. I've updated the styling to use a menu on the medium size screens as well.

[toc] | [prev] | [next] | [standalone]

#40163

On 2021-05-26, Michael Haufe (TNO) <tno@thenewobjective.com> wrote:
> On Wednesday, May 26, 2021 at 11:00:24 AM UTC-5, Jon Ribbens wrote:
>> On 2021-05-26, Michael Haufe (TNO) <t...@thenewobjective.com> wrote: 
>> > Paper has predefined standard sizes, as do viewports. Web developers 
>> > generally use media queries to target those sizes and act accordingly.
>> That's not right. Viewports don't come in standard sizes. But some 
>> frameworks have specific cut-off points at which you can make things 
>> switch layouts because changing the layout for smaller screens is 
>> often a good idea and testing your site on every width between 100px 
>> and 4,000 px is impractical ;-)
>
> Screen resolutions definitely do have standard sizes. That's what
> VGA, SGA, XGA, HD, 4K UHD, and others are:

Sure, but since the late 1980s people have tended to use graphical
windowing systems whereby applications don't take up the entire monitor
;-)

>> I don't think that's what the name means. It means the layout can 
>> change shape, like a liquid can change shape. There's no implication 
>> that the layout always fills 100% of the container like a liquid does.
>
> Given that layouts are and have been primarily boxes I don't think
> changing shape is relevant here for the definition unless you are
> referring to multiple independent boxes moving their positions
> dynamically.

That's exactly what I mean.

> Since we disagree on the definition, do you have a reference for your usage?

All of your references are fine for my definition I think, except the
first one.

>> > 'vw' is a relative measurement, so yes it will change.
>> That's *why* the text layout won't change. Try it.
>
> It resizes based on the viewport size. Just resize the webpage to see
> the behavior. What does "text layout" have to do with it? Are you
> referring to wrapping behavior?

Yes. If you use 'font-size: 1vw' then as you resize the page it remains
a solid, fixed layout, just scaling up and down like a piece of paper
would in a magnifier - i.e. exactly like old-fashioned paper design.

>> It's mostly that the viewport has to be very wide indeed before the
>> icon labels appear.
>
> No longer. I've updated the styling to use a menu on the medium size
> screens as well.

I think that's an improvement :-)

[toc] | [prev] | [next] | [standalone]

#40213

Michael Haufe (TNO):

> On Wednesday, May 26, 2021 at 9:15:12 AM UTC-5, Jon Ribbens wrote:
>> On 2021-05-26, Michael Haufe (TNO) <t...@thenewobjective.com> wrote:
>>> On Wednesday, May 26, 2021 at 8:56:59 AM UTC-5, Jon Ribbens wrote: 
>>> [...]
>>>> Using 'viewport width' for the font size *isn't* fluid, it's the 
>>>> exact opposite. It's paper-based thinking in a paperless world. 
>>>> It means the content doesn't format itself appropriately for the 
>>>> page, it just shrinks and expands like a photocopier on 'enlarge' 
>>>> mode. 
>>>
>>> Given that the common practice is to use breakpoints, are those not 
>>> the web equivalent of paper based thinking?
>> Why would they be?
> 
> Paper has predefined standard sizes, as do viewports. Web developers 
> generally use media queries to target those sizes and act accordingly. 

Wrong.

Viewports come in many sizes. It's the arrogance of designes who only
work with macOS and iOS to see the world as only three sizes: iPhone,
iPad and macBook.

In reality you have dozens of variations and the media queries are just
there to decide if you use the layout for desktop browsers or for mobile
browsers and sometimes tablets are also a thing to consider, but
nowadays many tables work fine using the desktop layout as well.

Within one layout the design is fluid of course - the mobile version of
a website works fine on a iPhone as well as on a Samsung Android Phone
or Google Pixel even if the viewport on all devices is different. Also
the desktop version does not care if your viewport is 120em wide or just
80em. The "deskop" layout should work for both cases and of course the
font should not become larger just because the viewport is 120em wide
and not just 80em.


-- 
Arno Welzel
https://arnowelzel.de

[toc] | [prev] | [next] | [standalone]

#40212

Michael Haufe (TNO):

> On Wednesday, May 26, 2021 at 8:56:59 AM UTC-5, Jon Ribbens wrote:
>> [...]
>> Those articles seem deeply confused, especially the first, which says: 
>>
>> This might be because typography is so deeply rooted in the 
>> centuries-old history of typesetting. The concept of having “fluid” 
>> anything is often at odds with this tradition. In print, dimensions 
>> have always been fixed, but they don’t need to be on the web. That’s 
>> why I think fluid typography is a perfect match for the web. It’s a 
>> different approach for a completely different medium. 
>>
>> Using 'viewport width' for the font size *isn't* fluid, it's the 
>> exact opposite. It's paper-based thinking in a paperless world. 
>> It means the content doesn't format itself appropriately for the 
>> page, it just shrinks and expands like a photocopier on 'enlarge' 
>> mode. 
> 
> Given that the common practice is to use breakpoints, are those not the web equivalent of paper based thinking? 

No.

Breakpoints are usally only based on the *widht* of a viewport and used
to decide wether there is enough room for two or more columns.

For the mobile version one would only display one column since a
viewport which is only 40em wide may not provide enough room for content
*and* a side bar. On the other hand a desktop viewport with 60em or more
there provides enough space for a 40em wide content area and a 20em wide
sidebar.

But in both cases I would never try to connect the font size to the
viewport width or height. I don't want to get text on a mobile device
way smaller just because the viewport is smaller. Also I want to see
*more* text on a desktop and not *bigger* text. Good responsive layout
will use a *different* layout which fits the smaller viewport and not
just scale everything to become smaller.


-- 
Arno Welzel
https://arnowelzel.de

[toc] | [prev] | [next] | [standalone]

#40211

Michael Haufe (TNO):

> On Wednesday, May 26, 2021 at 8:21:10 AM UTC-5, Jon Ribbens wrote:
>> On 2021-05-26, Michael Haufe (TNO) <t...@thenewobjective.com> wrote: 
>>> On Wednesday, May 26, 2021 at 1:33:27 AM UTC-5, Mostowski Collapse wrote: 
>>>> Hint, if you want to make websites that work 
>>>> on mobile and desktop, there are other 
>>>> approaches than just having elephant font size. 
>>>
>>> The font size is relative to the viewport size.
>> That's a pretty weird thing to do, to be fair.
> 
> Uncommon yes, but not that weird:
> 
> <https://www.smashingmagazine.com/2016/05/fluid-typography/>
> <https://web.archive.org/web/20200926083516/https://www.csshero.org/css-viewport-units-css-hero/>
> <https://css-tricks.com/viewport-sized-typography/>

I think someone misunderstood the idea of viewport based units. Viewport
based units are ok for the overall layout. But having *text* sized based
on the viewport makes no sense at all besides any demo to show what cool
tricks people found out. Also see the demo on
<https://css-tricks.com/viewport-sized-typography/> with the "I resize."
text which always fits the viewport - nobody needs this for *real*
textual content except a few special use cases to display banners etc..

A font size of 1 em is *always* readable on *any* device since the
browser is designed this way that "1 em" is the normal font size. So
using other font sizes should only be done for a good reason, e.g.
bigger fonts for headlines or using a big font to display a single short
message which fills the viewport. But usually you don't use dynamic font
sizes just because the size of the viewport changes.

For example:

Normally I don't use my desktop browser full screen since most sites
don't need it and don't use a full width view port to display more
information anyway. But in some cases I put the browser to full screen
size to make use of it - e.g. when using an online project management
tool where the additional space can be used to display more columns on
the kanban board etc.. It would be totally stupid if the font then would
be enlarged just because the viewport is bigger.

Or in other words: when I as a user make the viewport bigger or smaller
I don't want to get bigger or smaller text but more or less content.

-- 
Arno Welzel
https://arnowelzel.de

[toc] | [prev] | [next] | [standalone]

#40151

Nothing wrong with the name Dogelog,
Jon Ribbens doesn't like it, so what.

Mark- schrieb:
> Mostowski Collapse wrote:
> 
>> And maybe update your shitty website:
>> https://thenewobjective.com/about
>>
>> I have never seen a more sadenning thing.
>> Also the font size is way too large, cant
>> read anything without getting headache.
> 
> Nothing wrong with his website. You don't like it, so what.
> 

[toc] | [prev] | [next] | [standalone]

#40209

Mostowski Collapse:

> Nothing wrong with the name Dogelog,
> Jon Ribbens doesn't like it, so what.

Well - design is matter of taste (except when violating accessibility
guidelines). But there are also technical errors:

<https://validator.w3.org/nu/?doc=https%3A%2F%2Fthenewobjective.com%2F>


-- 
Arno Welzel
https://arnowelzel.de

[toc] | [prev] | [next] | [standalone]

#40214

On Sunday, June 13, 2021 at 10:55:34 AM UTC-5, Arno Welzel wrote:
> Mostowski Collapse:
> > Nothing wrong with the name Dogelog, 
> > Jon Ribbens doesn't like it, so what.
> Well - design is matter of taste (except when violating accessibility 
> guidelines). But there are also technical errors: 
> 
> <https://validator.w3.org/nu/?doc=https%3A%2F%2Fthenewobjective.com%2F>

I appreciate the code review. The remaining issues are a problem with jekyll/kramdown parsing of which there is not a trivial workaround currently.

I don't see the relevance to the current thread though.

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.lang.javascript

csiph-web